11 ms·

Thousands of Debian packages updated from their upstream Git repository

159 points by ecliptik 5y ago

craigds 5y ago
The graph insinuates that before etch (2007) close to 100% of debian's upstream packages didn't use any source control at all. Is that right? It seems like it couldn't possibly be true.
- carreau 5y ago
  IIRC before 2007 debian policy was that packages had to be installed from tarball even if a repo existed. Thus it is likely that the info about the repository was simply not tracked. It might still be the case for many packages. It stemmed from the fact that often releases tars might not be exactly the same as asking git to do a tarfile. For example releasing Python packages may require a build step and installing from PyPI or a git repo is sometime not the same.
  - geofft 5y ago
    That's still the norm! You're supposed to use the upstream tarball if one exists, and all of the tooling expects a tarball of some sort. In fact there's an active discussion right now on debian-devel about maybe changing the norms to prefer VCS archives to upstream release tarballs (and rerunning any of the code generation steps like autoconf as part of the Debian build): https://lists.debian.org/debian-devel/2021/08/msg00133.html https://lists.debian.org/debian-devel/2021/08/msg00133.html ... Also, the tooling not only expects a tarball, it expects every tarball with the same name to be bit-identical. So if foo 1.0 is already in Debian, you'd better not generate a slightly different foo-1.0.orig.tar.gz when you do a packaging update but you're still packaging version 1.0 of the upstream sources. In 2007 a tool called "pristine-tar" showed up to allow you to compute just enough information to regenerate the actual foo-1.0.orig.tar.gz from the foo 1.0 VCS tag and commit that delta onto a separate VCS branch. It's a pretty crucial but extremely finicky part of most workflows involving maintaining Debian packages via a VCS. And then it turns out that the author of pristine-tar actually was somewhat trying to "point out absurdities in the way things are done" (https://joeyh.name/blog/entry/twenty_years_of_free_software_--_part_5_pristine-tar/ https://joeyh.name/blog/entry/twenty_years_of_free_software_...) and people just happily adopted the tool and made things more absurd.
    - carreau 5y ago
      I'm not using debian that much anymore, but I'd be happy to make any changes upstream to make it easier on debian. When possible I try to have reproducible builds (https://reproducible-builds.org/ https://reproducible-builds.org/) that respect SOURCE_DATE_EPOCH extracted from the commit datetime. At least for IPython I alway build twice to make sure the sha is identical. I'd also be happy to have a way to signal to debian that there is a new release instead of having QA watch have to scan things regularly.
      - southerntofu 5y ago
        > I'd also be happy to have a way to signal to debian that there is a new release instead of having QA watch have to scan things regularly. That would be great! Unfortunately the current forging model is very centralized, centered around the UX of private companies with their internal teams and little (if any) outside cooperation. That's why we need decentralized forging systems: https://staticadventures.netlib.re/blog/decentralized-forge/ https://staticadventures.netlib.re/blog/decentralized-forge/ There's an ongoing 5000€ bounty for implementing ForgeFed federation (based on ActivityPub) on top of Gitea, in case you know people familiar with golang/ActivityPub who'd like to help. Also worth noting, i feel like there is room for experimenting with anti-authoritarian forging where you don't need upstream permission to receive webhooks (or other update notification). I've started experimenting with this but still pre-alpha quality: https://thunix.net/~southerntofu/forge/ https://thunix.net/~southerntofu/forge/ > All of these CI/CD plateforms consider the repository itself should contain the tasks to be run, for example in a .gitlab-ci.yml file. This top-down deployment model is well suited to an organization controling the whole of its software supply chain, but is a severe restriction to 3rd party involvement, which mostly hinders volunteer-run projects. > The forge suite adopts an opposite approach, where anyone can receive updates from remote repositories, and run the tasks they wish. This allows anyone within or without your projects to setup new test suites, benchmarks, and integrations. The applications are endless and should benefit your projects in many ways.
      - grlass 5y ago
        For those interested in reproducible builds, the gitian [1] project is a fairly simple VM which sets the up the necessary environment for doing this sort of thing. The tooling and community around reproducible builds is growing all the time, and imo we should be insisting on it for things such as government apps. [1] https://github.com/devrandom/gitian-builder https://github.com/devrandom/gitian-builder
- duskwuff 5y ago
  It's plausible. A lot of Debian packages come from small projects, often ones with a single developer. Before 2007, there weren't a lot of options for public source control -- GitHub didn't exist yet, SourceForge's CVS/SVN hosting was a pain to work with, and hosting it yourself was even more of a pain. Many of these small projects were probably only available as release tarballs, so that's what Debian built from.
  - blihp 5y ago
    I guess it depended on which part of the open source crowd you were/are involved with. Pretty much every project I cared about back then, as far back as the mid- to late-90's, had propped up a self-hosted vcs server. I used to run a personal svn server which wasn't that big a deal to set up and nearly zero effort to maintain. Where svn fell apart was the distributed part of the equation: it worked fine for the core developers who had commit access, not so great for anyone else who wanted to contribute back. Even today there are number of projects that are still resistant to git (i.e. git, not github) and clinging to svn.
    - oblio 5y ago
      If even FreeBSD switched to Git I don't think there's any reason for other projects to not do the same, other than inertia/lack of resources. And I'm saying this as someone who's not super fond of Git (especially the UI).
      - zinekeller 5y ago
        > If FreeBSD switched to Git If? It already happened: https://forums.freebsd.org/threads/heads-up-freebsd-changing-from-subversion-to-git-this-weekend.78087/ https://forums.freebsd.org/threads/heads-up-freebsd-changing...
        oblio 5y ago
        Rephrased.
    - 5y ago
- deleted 5y ago
  [deleted]
- colechristensen 5y ago
  Upstream projects likely used source control, but the packages used published artifacts (tarballs) which were released by the upstream project. It's a statement that gives false impressions, the reality isn't very interesting.
- geofft 5y ago
  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.
  - da39a3ee 5y ago
    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 5y ago
      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.)
- jwilk 5y ago
  I think what this graph shows is, contrary to what the text alludes, the VCS use for Debian packaging. There was no standardized way to declare that until late 2006, and it was offically documented only in 2008: https://bugs.debian.org/391023 https://bugs.debian.org/391023
carreau 5y ago
> The QA watch service regularly polls all watch locations in the archive and makes the information available, so it’s possible to know which packages have changed without downloading each one of them. Is there a way to notify the watch service of a new version to avoid (or decrease frequency) of regular polling ?
- andrewshadura 5y ago
  Not exactly, but there's a validation page which can trigger a re-fetch.
someperson 5y ago
Is the process of migrating fresh-snapshots to Debian Sid automated?
- rincebrain 5y ago
  It seems like a logical option to eventually offer if it doesn't already (which I presume it doesn't, or the post would have mentioned it) - [1] is a post about the bot cutting PRs when it finds other things it thinks it knows how to correct. [1] - https://www.jelmer.uk/janitor-update-2.html https://www.jelmer.uk/janitor-update-2.html
myself248 5y ago
How does this affect our vulnerability to various software-supply-chain attacks?
- dane-pgp 5y ago
  > Of course, since these packages are built automatically without human supervision it’s likely that some of them will have bugs in them that would otherwise have been caught by the maintainer. Human supervision isn't enough to protect the supply chain, and I can't think of a time that it's actually stopped an attack at the packaging stage, but having some extra "friction" in the process seems like it should be a benefit. Ideally an attacker would have to get past both the upstream author and the Debian maintainer, rather than these being two separate single points of failure. Fortunately the Debian project is improving the situation with regards to supply chain attacks by continuing to work on Reproducible Builds. I think the next step from there needs to be Binary Transparency, with the adoption of the sort of approach being trialled by Arch Linux: https://github.com/kpcyrd/pacman-bintrans https://github.com/kpcyrd/pacman-bintrans
  - arminiusreturns 5y ago
    Oh cool, I didn't know about this. It's always been something I've been concerned about, but wasn't sure how to address. I like their summary: Cryptographic signatures prove that a message originates from somebody with control over the private key, but it's impossible to prove that the private key didn't sign additional messages. In update security this means a signed update is a strong indicator the update is authentic, but you can't be sure this update is the same update everybody else got. Somebody in control of the update key could craft a malicious update, sign it and feed it specifically to you.
    - stragies 5y ago
      To alleviate that concern a bit, Debian apt can be configured to fetch updates via TOR, so that it becomes (more) difficult to send YOU -specifically- a doctored update.
  - 5y ago
encryptluks2 5y ago
Ian Murdock is considered the founder of Debian, but he shifted his efforts to Alpine Linux while working at Docker. I personally find Alpine and Arch packaging so much easier overall.
jancsika 5y ago
There should be a special case for patches related to systemd: * train an ML model on all the systemd Debian flamewars * for each merge proposed related to systemd, create random(0, 50) accounts and have them instantly simulate an entire flame for that merge request * lock the thread after random(0, 100) posts This system guarantees that the relevant dev arrives to the merge request after the flame war has subsided.
wiz21c 5y ago
I hope to live long enough to see TOTAL AUTOMATION (tm) !!! Joking aside, this is truly impressive. Even if it is just a logical step, it's great to see that a group of independent people (i.e. not paid by a single company) can coordinate at that level... (I come from an age where swapping floppy disks to share code was acceptable)
- oblio 5y ago
  > I come from an age where swapping floppy disks to share code was acceptable You mean... from the age of Debian? :-) How many floppies was the original install? Something like 15?
  - wiz21c 5y ago
    I mean 20 years older than Debian :-) I'm old enough to have heard people says that source control was going to slow down development :-) Been using Debian for about 20 years I think. Gradually moved from unstable to testing to stable, I'm getting old :-)
- thomastjeffery 5y ago
  If you want to see something incredibly close, take a look at NixOS.
aitchnyu 5y ago
What's the CI test suite look like? Does Debian create and execute test for CLI and GUI interactions?
- teddyh 5y ago
  https://wiki.debian.org/ContinuousIntegration/autopkgtest https://wiki.debian.org/ContinuousIntegration/autopkgtest
- bregma 5y ago
  It's discussed fairly early in the article.
rbanffy 5y ago
The only repo I manage that's packaged in Debian is used by the packager as a base, but they work directly off a fork (https://github.com/kilobyte/3270font https://github.com/kilobyte/3270font) of my repo (https://github.com/rbanffy/3270font https://github.com/rbanffy/3270font) to generate packages. As far as I understand, Adam publishes many other packages and has an automated workflow for that. They end directly on Sid.
debian_oldtimer 5y ago
Debian Developer here. Automating some parts of packaging does not remove the important part: reviewing the code, checking for past security issues, adding sandboxing, removing privacy breaches, testing that package works well. Packaging for Debian is not meant to be a 5 minutes effort like some other distributions - by design. It takes work to make sure users can trust some software.
- thomastjeffery 5y ago
  All of those parts you mentioned can be done independent of packaging.
  - debian_oldtimer 5y ago
    No. Packaging is completed when you sign a package and upload it into Debian. Taking responsibility for its quality is part of the process.
    - thomastjeffery 5y ago
      Within the boundaries of the current system, sure, but it still can be accomplished. So long as builds are reproducible, signing and responsibility can be done entirely at the source control end. If you want an example, just look at Nixpkgs.
      - debian_oldtimer 5y ago
        No, it's not enough.
- jelmer 5y ago
  I don't disagree - I'm not suggesting anywhere that this be used to directly upload to unstable. There's definitely a class of users who would like the balance between freshness and quality to be closer to freshness for some packages. There's a big warning on https://janitor.debian.net/fresh https://janitor.debian.net/fresh about the packages not having had human review, and the last paragraph of the blog post mentions this as well. That said, I do believe strongly that we can let automation take care of more of the (boring bits) of the packaging process even for unstable, and leave the interesting bits that automation can't help with to the humans.

159 points by ecliptik 5y ago

The graph insinuates that before etch (2007) close to 100% of debian's upstream packages didn't use any source control at all. Is that right? It seems like it couldn't possibly be true.

carreau 5y ago
IIRC before 2007 debian policy was that packages had to be installed from tarball even if a repo existed. Thus it is likely that the info about the repository was simply not tracked. It might still be the case for many packages. It stemmed from the fact that often releases tars might not be exactly the same as asking git to do a tarfile. For example releasing Python packages may require a build step and installing from PyPI or a git repo is sometime not the same.
- geofft 5y ago
  That's still the norm! You're supposed to use the upstream tarball if one exists, and all of the tooling expects a tarball of some sort. In fact there's an active discussion right now on debian-devel about maybe changing the norms to prefer VCS archives to upstream release tarballs (and rerunning any of the code generation steps like autoconf as part of the Debian build): https://lists.debian.org/debian-devel/2021/08/msg00133.html https://lists.debian.org/debian-devel/2021/08/msg00133.html ... Also, the tooling not only expects a tarball, it expects every tarball with the same name to be bit-identical. So if foo 1.0 is already in Debian, you'd better not generate a slightly different foo-1.0.orig.tar.gz when you do a packaging update but you're still packaging version 1.0 of the upstream sources. In 2007 a tool called "pristine-tar" showed up to allow you to compute just enough information to regenerate the actual foo-1.0.orig.tar.gz from the foo 1.0 VCS tag and commit that delta onto a separate VCS branch. It's a pretty crucial but extremely finicky part of most workflows involving maintaining Debian packages via a VCS. And then it turns out that the author of pristine-tar actually was somewhat trying to "point out absurdities in the way things are done" (https://joeyh.name/blog/entry/twenty_years_of_free_software_--_part_5_pristine-tar/ https://joeyh.name/blog/entry/twenty_years_of_free_software_...) and people just happily adopted the tool and made things more absurd.
  - carreau 5y ago
    I'm not using debian that much anymore, but I'd be happy to make any changes upstream to make it easier on debian. When possible I try to have reproducible builds (https://reproducible-builds.org/ https://reproducible-builds.org/) that respect SOURCE_DATE_EPOCH extracted from the commit datetime. At least for IPython I alway build twice to make sure the sha is identical. I'd also be happy to have a way to signal to debian that there is a new release instead of having QA watch have to scan things regularly.
    - southerntofu 5y ago
      > I'd also be happy to have a way to signal to debian that there is a new release instead of having QA watch have to scan things regularly. That would be great! Unfortunately the current forging model is very centralized, centered around the UX of private companies with their internal teams and little (if any) outside cooperation. That's why we need decentralized forging systems: https://staticadventures.netlib.re/blog/decentralized-forge/ https://staticadventures.netlib.re/blog/decentralized-forge/ There's an ongoing 5000€ bounty for implementing ForgeFed federation (based on ActivityPub) on top of Gitea, in case you know people familiar with golang/ActivityPub who'd like to help. Also worth noting, i feel like there is room for experimenting with anti-authoritarian forging where you don't need upstream permission to receive webhooks (or other update notification). I've started experimenting with this but still pre-alpha quality: https://thunix.net/~southerntofu/forge/ https://thunix.net/~southerntofu/forge/ > All of these CI/CD plateforms consider the repository itself should contain the tasks to be run, for example in a .gitlab-ci.yml file. This top-down deployment model is well suited to an organization controling the whole of its software supply chain, but is a severe restriction to 3rd party involvement, which mostly hinders volunteer-run projects. > The forge suite adopts an opposite approach, where anyone can receive updates from remote repositories, and run the tasks they wish. This allows anyone within or without your projects to setup new test suites, benchmarks, and integrations. The applications are endless and should benefit your projects in many ways.
    - grlass 5y ago
      For those interested in reproducible builds, the gitian [1] project is a fairly simple VM which sets the up the necessary environment for doing this sort of thing. The tooling and community around reproducible builds is growing all the time, and imo we should be insisting on it for things such as government apps. [1] https://github.com/devrandom/gitian-builder https://github.com/devrandom/gitian-builder
duskwuff 5y ago
It's plausible. A lot of Debian packages come from small projects, often ones with a single developer. Before 2007, there weren't a lot of options for public source control -- GitHub didn't exist yet, SourceForge's CVS/SVN hosting was a pain to work with, and hosting it yourself was even more of a pain. Many of these small projects were probably only available as release tarballs, so that's what Debian built from.
- blihp 5y ago
  I guess it depended on which part of the open source crowd you were/are involved with. Pretty much every project I cared about back then, as far back as the mid- to late-90's, had propped up a self-hosted vcs server. I used to run a personal svn server which wasn't that big a deal to set up and nearly zero effort to maintain. Where svn fell apart was the distributed part of the equation: it worked fine for the core developers who had commit access, not so great for anyone else who wanted to contribute back. Even today there are number of projects that are still resistant to git (i.e. git, not github) and clinging to svn.
  - oblio 5y ago
    If even FreeBSD switched to Git I don't think there's any reason for other projects to not do the same, other than inertia/lack of resources. And I'm saying this as someone who's not super fond of Git (especially the UI).
    - zinekeller 5y ago
      > If FreeBSD switched to Git If? It already happened: https://forums.freebsd.org/threads/heads-up-freebsd-changing-from-subversion-to-git-this-weekend.78087/ https://forums.freebsd.org/threads/heads-up-freebsd-changing...
      - oblio 5y ago
        Rephrased.
  - 5y ago
deleted 5y ago
[deleted]
colechristensen 5y ago
Upstream projects likely used source control, but the packages used published artifacts (tarballs) which were released by the upstream project. It's a statement that gives false impressions, the reality isn't very interesting.
geofft 5y ago
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.
- da39a3ee 5y ago
  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 5y ago
    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.)
jwilk 5y ago
I think what this graph shows is, contrary to what the text alludes, the VCS use for Debian packaging. There was no standardized way to declare that until late 2006, and it was offically documented only in 2008: https://bugs.debian.org/391023 https://bugs.debian.org/391023

carreau 5y ago

> The QA watch service regularly polls all watch locations in the archive and makes the information available, so it’s possible to know which packages have changed without downloading each one of them. Is there a way to notify the watch service of a new version to avoid (or decrease frequency) of regular polling ?

andrewshadura 5y ago
Not exactly, but there's a validation page which can trigger a re-fetch.

someperson 5y ago

Is the process of migrating fresh-snapshots to Debian Sid automated?

rincebrain 5y ago
It seems like a logical option to eventually offer if it doesn't already (which I presume it doesn't, or the post would have mentioned it) - [1] is a post about the bot cutting PRs when it finds other things it thinks it knows how to correct. [1] - https://www.jelmer.uk/janitor-update-2.html https://www.jelmer.uk/janitor-update-2.html

myself248 5y ago

How does this affect our vulnerability to various software-supply-chain attacks?

dane-pgp 5y ago
> Of course, since these packages are built automatically without human supervision it’s likely that some of them will have bugs in them that would otherwise have been caught by the maintainer. Human supervision isn't enough to protect the supply chain, and I can't think of a time that it's actually stopped an attack at the packaging stage, but having some extra "friction" in the process seems like it should be a benefit. Ideally an attacker would have to get past both the upstream author and the Debian maintainer, rather than these being two separate single points of failure. Fortunately the Debian project is improving the situation with regards to supply chain attacks by continuing to work on Reproducible Builds. I think the next step from there needs to be Binary Transparency, with the adoption of the sort of approach being trialled by Arch Linux: https://github.com/kpcyrd/pacman-bintrans https://github.com/kpcyrd/pacman-bintrans
- arminiusreturns 5y ago
  Oh cool, I didn't know about this. It's always been something I've been concerned about, but wasn't sure how to address. I like their summary: Cryptographic signatures prove that a message originates from somebody with control over the private key, but it's impossible to prove that the private key didn't sign additional messages. In update security this means a signed update is a strong indicator the update is authentic, but you can't be sure this update is the same update everybody else got. Somebody in control of the update key could craft a malicious update, sign it and feed it specifically to you.
  - stragies 5y ago
    To alleviate that concern a bit, Debian apt can be configured to fetch updates via TOR, so that it becomes (more) difficult to send YOU -specifically- a doctored update.
- 5y ago

encryptluks2 5y ago

Ian Murdock is considered the founder of Debian, but he shifted his efforts to Alpine Linux while working at Docker. I personally find Alpine and Arch packaging so much easier overall.

jancsika 5y ago

There should be a special case for patches related to systemd: * train an ML model on all the systemd Debian flamewars * for each merge proposed related to systemd, create random(0, 50) accounts and have them instantly simulate an entire flame for that merge request * lock the thread after random(0, 100) posts This system guarantees that the relevant dev arrives to the merge request after the flame war has subsided.

wiz21c 5y ago

I hope to live long enough to see TOTAL AUTOMATION (tm) !!! Joking aside, this is truly impressive. Even if it is just a logical step, it's great to see that a group of independent people (i.e. not paid by a single company) can coordinate at that level... (I come from an age where swapping floppy disks to share code was acceptable)

oblio 5y ago
> I come from an age where swapping floppy disks to share code was acceptable You mean... from the age of Debian? :-) How many floppies was the original install? Something like 15?
- wiz21c 5y ago
  I mean 20 years older than Debian :-) I'm old enough to have heard people says that source control was going to slow down development :-) Been using Debian for about 20 years I think. Gradually moved from unstable to testing to stable, I'm getting old :-)
thomastjeffery 5y ago
If you want to see something incredibly close, take a look at NixOS.

aitchnyu 5y ago

What's the CI test suite look like? Does Debian create and execute test for CLI and GUI interactions?

teddyh 5y ago
https://wiki.debian.org/ContinuousIntegration/autopkgtest https://wiki.debian.org/ContinuousIntegration/autopkgtest
bregma 5y ago
It's discussed fairly early in the article.

rbanffy 5y ago

The only repo I manage that's packaged in Debian is used by the packager as a base, but they work directly off a fork (https://github.com/kilobyte/3270font https://github.com/kilobyte/3270font) of my repo (https://github.com/rbanffy/3270font https://github.com/rbanffy/3270font) to generate packages. As far as I understand, Adam publishes many other packages and has an automated workflow for that. They end directly on Sid.

debian_oldtimer 5y ago

Debian Developer here. Automating some parts of packaging does not remove the important part: reviewing the code, checking for past security issues, adding sandboxing, removing privacy breaches, testing that package works well. Packaging for Debian is not meant to be a 5 minutes effort like some other distributions - by design. It takes work to make sure users can trust some software.

thomastjeffery 5y ago
All of those parts you mentioned can be done independent of packaging.
- debian_oldtimer 5y ago
  No. Packaging is completed when you sign a package and upload it into Debian. Taking responsibility for its quality is part of the process.
  - thomastjeffery 5y ago
    Within the boundaries of the current system, sure, but it still can be accomplished. So long as builds are reproducible, signing and responsibility can be done entirely at the source control end. If you want an example, just look at Nixpkgs.
    - debian_oldtimer 5y ago
      No, it's not enough.
jelmer 5y ago
I don't disagree - I'm not suggesting anywhere that this be used to directly upload to unstable. There's definitely a class of users who would like the balance between freshness and quality to be closer to freshness for some packages. There's a big warning on https://janitor.debian.net/fresh https://janitor.debian.net/fresh about the packages not having had human review, and the last paragraph of the blog post mentions this as well. That said, I do believe strongly that we can let automation take care of more of the (boring bits) of the packaging process even for unstable, and leave the interesting bits that automation can't help with to the humans.