[geofft]

Debian packaging is its own form of source control: there's a debian/changelog file with versions, and every time you submit something new to the Debian archive, it has to be a new version with a new changelog entry.

Debian also has a strong individual ownership culture of packages, and it was even stronger then. Each package has a listed maintainer (nowadays it's often a team, but there isn't an "everyone" team short of the Debian QA Group, which is who orphaned packages get reassigned to). While every Debian developer has technical access to upload every package, it's strongly socially frowned upon to upload someone else's package. So under that model, you don't really need the collaboration or concurrent-editing features of source control systems.

And yes, I remember that in about 2007 very few Debian packages had their packaging in any sort of standard version control tool (CVS, SVN, etc.) You'd get the sources via apt-get source, and then if you wanted to contribute, you could send in a patch by email to the bug tracker and the maintainer would incorporate it.

Of course there are a whole lot of other quality-of-life features that real version control systems get you, which is why people ended up adopting them. But it's not like there was a shared directory on a server somewhere that every Debian developer just edited in place or whatever.

[oblio]

> While every Debian developer has technical access to upload every package, it's strongly socially frowned upon to upload someone else's package.

I wonder how much malware is in there, that we haven't found, because of this. I'm willing to bet there is some in there, especially since at this point Debian is for sure targeted by professionals.

[goodpoint]

Debian is not only doing both peer review of the packages but it's reviewed by the users.

Also, packages are rebuilt from source centrally.

And finally, there is a number of large companies that provide legal indemnification, long term support and so on as part of large contracts.

I.e. a 20-years long contract to provide all the software for an airport, or all branches of a bank, or a family of medical devices or cruise ships.

Those companies review the distro very carefully.

[geofft]

Well, first off, if you're providing all the software for medical devices or an airport, you probably don't care everything in the OS. You care about the software going into your platform, and from a minimal-trusted-base / least-privilege standpoint, you probably want to minimize the amount of software you use to the extent possible, whether or not you review it. So it's unlikely they're auditing the entire distro.

Second, if these companies are in fact auditing the code (which is a lot of code!), as opposed to just selling insurance and hoping for the best, that means that

a) it's some employee's job to spend a portion of their time reviewing the code

b) when they find issues, they report those bugs somewhere, so that the bug gets fixed

Can you point to either a job posting that lists reviewing Debian packages as part of the job requirements (or equivalently, someone's résumé/LinkedIn that says they did this work), or a bug report from one of these auditors?

[goodpoint]

> So it's unlikely they're auditing the entire distro.

No, you are oversimplifying the complexity of tenths-of-million-dollar contracts by far.

You can go from a simple and cheap indemnification https://ubuntu.com/legal/ubuntu-advantage-assurance to guaranteeing long term backports for a small set of packages https://www.cip-project.org/ to much bigger efforts.

Some commercial distros and various internal-only distros have a legal team to do license review. That's just the first step.

You can easily find jobspecs for security analysts in tech companies, or system engineers hired to handle the software lifecycle.

I opened the bug reports you are mentioning myself, and security advisories. I cannot name companies and colleagues, obviously, otherwise I would have done it already. The companies I work[ed] for rebuild entire ecosystems of packages, do legal review but don't do security audit on things like games.

[da39a3ee]

As a developer of an application, I have no special relationship with Debian. It’s nice they exist, and I do recognize the important role they’ve played in Linux, but still as a maintainer & author I don’t care about them and their practices and requirements any more than Homebrew, or a bunch of other Linux distros/packaging projects. Is what you wrote consistent with what I just wrote?

[kzrdude]

Debian is almost like a trusted retail shop. They mediate between you (the producer of the software) and me (the consumer of the software). The quality control they are responsible for, does make them a trusted "shop" for the users - for example, one believes that using debian packages protects from malware.

It's natural the user cares more about this system than the producer - for the producer it looks like hassle and a middleman.

(Sidenote: Sometimes I'm the producer side of debian packages too.)

[da39a3ee]

> Sometimes I'm the producer side of debian packages too.

But my point is there's no such thing as creating a "debian package" from the producer side. We create software to be used on certain operating systems; perhaps only unix-like OSs. But we don't produce software "for debian".

[account42]

> But we don't produce software "for debian".

Most don't, but you can provide a debian repository for your software, e.g. if you care about debian users having newer versions available.

[geofft]

I do mot think that what you wrote and what I wrote intersect in any way, to the point where I'm wondering if you replied to the wrong comment. (So, yes, they're consistent.)

I'm discussing how Debian handles versioning for the packaging scripts/metadata, which are effectively a very small software project that depends on your project. Those practices are no more relevant to you than some third-party software project project that compiles yours and uses it as a library, or some Ansible playbook that installs your project, or whatever. You might be interested in the existence of those projects and might want to address bugs they find, but whether they use version control is quite irrelevant to you.

[da39a3ee]

I did mean to reply to your comment, but sorry if I've conflated packaging and application development. It was this sentence that confused me most:

> in about 2007 very few Debian packages had their packaging in any sort of standard version control tool (CVS, SVN, etc.) You'd get the sources via apt-get source, and then if you wanted to contribute, you could send in a patch by email to the bug tracker and the maintainer would incorporate it.

Here I think you're using "contribute" to refer to contributing to the application codebase, not the packaging codebase. But why would contributing to the application codebase have anything to do with Debian technology such as apt-get source and a debian bug tracker, and why would the maintainer pick up patches from such places? Surely, to contribute to the application you go to the application homepage (often Github nowadays) and open a PR?

[geofft]

No, I mean contributing to the packaging codebase. That graph is from https://trends.debian.net/#version-control-system , which has information about Debian packaging codebases ("source packages").

If anyone other than the package's maintainer / member of the maintaining team (whether a fellow Debian developer, an upstream author/contributor, or a user) has a contribution to make to the Debian package, they should contact the Debian maintainer. In 2007, for almost every package, the only way to do that would be to send the maintainer a patch file, generally through the Debian bug tracking system. (Nowadays, the majority of Debian packaging repos are on https://salsa.debian.org, a GitLab instance, and you can usually open a merge request there and maintainers will notice and accept them.)

The Debian packaging repo consists of, effectively, a build recipe and possibly pre/post install/remove scripts to run on the end user's system. (In practice there are common tools to do the build and to generate those scripts, so you'll find a lot of files to influence the behavior of such tools.) It can also consist of extra changes added by Debian, such as missing manpages or translations, or even patches to the code.

If you have a change to make to a piece of software packaged in Debian, but it's unsuitable for the upstream repo, you can send it to the Debian maintainer and ask them to include it in the packaging repo.

(It also used to be a vague norm that you would always contact the Debian maintainer, who would forward contributions onto upstream if suitable. It's questionable whether that was the right model, and it's certainly not the norm today.)