There is some nuance to this. Adding comments to the stated goal "Everyone who interacts with Debian source code (1) should be able to do so (2) entirely in git:
(1) should be able does not imply must, people are free to continue to use whatever tools they see fit
(2) Most of Debian work is of course already git-based, via Salsa [1], Debian's self-hosted GitLab instance. This is more about what is stored in git, how it relates to a source package (= what .debs are built from). For example, currently most Debian git repositories base their work in "pristine-tar" branches built from upstream tarball releases, rather than using upstream branches directly.
This is a misunderstanding of what Git does. Git is a Merkle hash tree, content-addressed, immutable/append-only filesystem, with commits as objects that bind a filesystem root by its hash. The diffs that make up a commit are not really its contents -- they are computed as needed. Now most of the time it's best to think of Git as a patch quilting porcelain, but it's really more than that, and while you can get very far with the patch quilting porcelain model, at some point you need to understand that it goes deeper.
The whole patch quilting thing is awful. Just keep the patches as commits. It won't "trick" me or anyone else, especially if you keep them in branches that denote "debian".
Please, please, stop the nonsense with the patch quilting -- it's really cumbersome, it adds unnecessary cognitive load, it raises the bar to contributions, it makes maintenance harder, and it adds _zero value_. Patch quilting is a lose-lose proposition.
> The whole patch quilting thing is awful. Just keep the patches as commits.
I'd say that `quilt` the utility is pretty much abandoned at this point. The name `quilt` remains in the format name, but otherwise is not relevant.
Nowadays people that maintain patches do it via `gbp-pq` (the "patch queue" subcommand of the badly named `git-buildpackage` software). `gbp-pq switch` reads the patches stored in `debian/patches/`, creates an ephemeral branch on top of the HEAD, and replays them there. Any change done to this branch (new commits, removed comments, amended commits) are transformed by `gbp-pq export` into a valid set of patches that replaces `debian/patches/`.
This mechanism introduces two extra commands (one to "enter" and one to "exit" the patch-applied view) but it allows Debian to easily maintain a mergeable Git repo with floating patches on top of the upstream sources. That's impossible to do with plain Git and needs extra tools or special workflows even outside of Debian.
What siblings say. What you want is `git rebase`, especially with the `--onto` and `--interactive` options. You might also want something like bisect-rebase.sh[0], though there are several other things like it now.
It's worth mentioning the quilting approach likely predates the advent of git by at least a decade.. I think compatibility with git has been available for a while now and I assume there was always something more pressing than migrating the base stack to git
https://wiki.debian.org/UsingQuilt but the short form is that you keep the original sources untouched, then as part of building the package, you apply everything in a `debian/patches` directory, do the build, and then revert them. Sort of an extreme version of "clearly labelled changes" - but tedious to work with since you need to apply, change and test, then stuff the changes back into diff form (the quilt tool uses a push/pop mechanism, so this isn't entirely mad.)
Quilt is difficult to maintain, but a quilt-like workflow? Easy: it's just a branch with all patches as commits. You can re-apply those to new releases of the upstream by using `git rebase --onto $new_upstream_commit_tag_or_branch`.
Oh, yes. This seems like nothing short of necessary for the long term viability of the project. I really hope this effort succeeds, thank you to everyone pushing this!
I can't find it now but I recently saw a graph of new Debian Developers joining the project over time and it has sharply declined in recent years. I was on track to becoming a Debian Developer (attended a couple DebConfs, got some packages into the archive, became a Debian Maintainer) but I ultimately burned out in large part because of how painful Debian's tooling makes everything. Michael Stapelberg's post about leaving Debian really rings true: https://michael.stapelberg.ch/posts/2019-03-10-debian-windin...
Debian may still be "getting by" but if they don't make changes like this Git transition they will eventually stop getting by.
What I've always found off-putting about the Debian packaging system is that the source lives with the packaging. I find that I prefer Ports-like systems where the packaging specifies where to fetch the source from. I find that when the source is included with the packaging, it feels more unwieldy. It also makes updating the package clumsier, because the packager has to replace the embedded source, rather than just changing which source tarball is fetched in the build recipe.
Debian requires that packages be able to be built entirely offline.
> Debian guarantees every binary package can be built from the available source packages for licensing and security reasons. For example, if your build system downloaded dependencies from an external site, the owner of the project could release a new version of that dependency with a different license. An attacker could even serve a malicious version of the dependency when the request comes from Debian's build servers. [1]
So do Gentoo and Nix, yet they have packaging separate from the source code. The source is fetched, but the build is sandboxed from the network during the configure, build and install phases. So it's technically possible.
Nix definitely does not allow most things to be built offline (at least in the way Debian means it).
With Nix, any fetcher will download the source. It does so in a way that guarantees the shasum of what is fetched is identical, and if you already have something in the nix store with that shasum, it won't have to fetch it.
However, with just a mirror of the debian source tree, you can build everything without hitting the internet. This is assuredly not true with just a mirror of nixpkgs.
There are probably still ways to maintain a source archive with a ports system. Just analyze the sources used by builds, create a mirror, and redirect fetches to use the mirror. It's not that crazy. The packaging would still be a separate affair.
OK, I see how the Debian idea differs from the Portage/Nix/etc. idea. For Portage and Nix it is enough that the build proper be offline, but the source code is fetched at the beginning of the package build. Not only do I find this sufficient, I prefer it because IMO it makes the package easier to work with (since you're only wrangling the packaging code, not upstream's).
Nix and specifically nixpkgs is IMO very bad at this. It's not a distro: it's a collection of random links that in many cases now only exists in cache.nixos.org. The tarball server frequently doesn't have content, can't represent some content at all (recursive hash types), links have rotted away completely (broadcom driver zips referencing a domain which is now advertising online gambling).
Nix isn't functional: it's a functional core that moved every bit of the imperative part to an even less parseable stage, labelled it "evaluation" and then ignored any sense of hygiene about it.
No: your dependency tree for packaging should absolutely not include an opaque binary from a cache server, or a link to a years old patch posted on someone else's bugzilla instance (frequently link rotted as well).
Nothing has made me appreciate the decisions of mainstream distributions more then dealing with an alternative like this.
All that is required for this to work (building offline) and be immune to all bad thing you wrote: package build part must contain checksum of source code archive and mirror that source code.
This doesn't say what you think it does. It says that every binary package should only depend on its declared source packages. It does not say that source packages must be constructed without an upstream connection.
What the OP was referring to, is that Debian's tooling stores the upstream code along with the debian build code. There is support tooling for downloading new upstream versions (uscan) and for incorporating the upstream changes into Debian's version control (uupdate) to manage this complexity, but it does mean that Debian effectively mirrors the upstream code twice: in its source management system (mostly salsa.debian.org nowadays), and in its archive, as Debian source archives.
This is such a wonderful guarantee to offer to users. In most cases, I trust the Debian maintainers more than a trust the upstream devs (especially once you take into account supply chain attacks).
It's sad how much Linux stuff is moving away from apt to systems like snap and flatpak that ship directly from upstream.
> I find that when the source is included with the packaging, it feels more unwieldy.
On the other hand, it makes for a far easier life when bumping compile or run time dependency versions. There's only one single source of truth providing both the application and the packaging.
It's just the same with Docker and Helm charts. So many projects insist on keeping sometimes all of them in different repositories, making change proposals an utter PITA.
Correct me if I’m wrong but as I’m understanding it, the processes is well underway towards moving the core systems and libraries (or whatever it’s all called) across to the new way. But that there’s a massive job of extended libraries maintained by lots of other parties and this ecosystem of libraries have been using all manner of approaches, each of which has its drawbacks and the big goal here is to get all these maintainers onboard to switch over to the new git-based workflow that this transition team (and others) have been working hard to make logical and easy enough to implement.
Is that a fair general read of the situation? (I have further comments to make but wanted to check my basic assumptions first).
Now if a consequence of that could be that one (as an author of a piece of not-yet-debianized software) can have the possibility to decently build Debian packages out of their own repository and, once the package is qualified to be included in Debian, trivially get the publish process working, that would be a godsend.
At the moment, it is nothing but pain if one is not already accustomed and used to building Debian packages to even get a local build of a package working.
The problem is that "once the package is qualified to be included in Debian" is _mostly_ about "has the package metadata been filled in correctly" and the fact that all your build dependencies also need to be in Debian already.
If you want a "simple custom repository" you likely want to go in a different direction and explicitly do things that wouldn't be allowed in the official Debian repositories.
For example, dynamic linking is easy when you only support a single Debian release, or when the Debian build/pkg infrastructure handles this for you, but if you run a custom repository you either need a package for each Debian release you care about and have an understanding of things like `~deb13u1` to make sure your upgrade paths work correctly, or use static binaries (which is what I do for my custom repository).
Most, because Debian is the only distro which strictly enforces their manpages and filesystem standards. And most source packages don't care much, resp. have other ideas
Lots. Because many upstream projects don't have their build system set up to work within a distribution (to get dependencies form the system and to install to standard places). All distros must patch things to get them to work.
Well, there are big differences in how aggressively things are patched. Arch Linux makes a point to strictly minimize patches and avoid them entirely whenever possible. That's a good thing, because otherwise, nonsense like the Xscreensaver situation ensues, where the original developers aggressively reject distro packages for mutilating their work and/or forcing old and buggy versions on unsuspecting users.
A fair few I expect, amongst actively developed apps/utils/libs. Away from sid (unstable) Debian packages are often a bit behind upstream but still supported, so security fixes are often back-ported if the upstream project isn't also maintaining older releases that happen to match the version(s) in testing/stable/oldstable.
The longer answer is that a lot of people already use Git for Debian version control, and the article expands on how this will be better-integrated in the future. But what goes into the archive (for building) is fundamentally just a source package with a version number. There's a changelog, but you're free to lie in it if you so wish.
Debian is kind of slow in adapting to the modern world.
I kind of appreciate that debian put FOSS at a core value
very early on; in fact, it was the first distribution I
used that forced me to learn the commandline. The xorg-server
or rather X11 server back then was not working so I only had
the commandline, and a lean debian handbook. I typed in the
commands and learned from that. Before this I had SUSE and it
had a much thicker book, with a fancypants GUI - and it was
utterly useless. But that was in 2005 or so.
Now, in 2025, I have not used debian or any debian based
distribution in a long time. I either compile from source
loosely inspired by LFS/BLFS; or I may use Manjaro typically
these days, simply because it is the closest to a modern
slackware variant (despite systemd; slackware I used for
a long time, but sadly it slowed down too much in the last
10 years, even with modern variants such as alienbob's
slackware variant - manjaro moves forward like 100x faster
and it also works at the same time, including when I want
to compile from source; for some reason, many older distributions
failed to adapt to the modern era. Systemd may be one barrier
here, but the issue is much more fundamental than that. For
instance, you have many more packages now, and many things
take longer to compile, e. g. LLVM and what not, which in turn
is needed for mesa, then we have cmake, meson/ninja and so
forth. A lot more software to handle nowadays).
> Debian is kind of slow in adapting to the modern world.
Yeah definitely. I guess this is a result of their weird idea that they have to own the entire world. Every bit of open source Linux software ever made must be in Debian.
If you have to upgrade the entire world it's going to take a while...
I remember when a startup I used to work for made the transition from svn to git. They transitioned, then threw the guy who suggested the transition under the bus; he quit, and then the company collapsed. Lol!
I was hired at a small startup (~15 employees total) and one of the first things I did was to migrate their SVN repository to Git. Not too difficult, brought over the history and then had to write a bunch of tooling to handle the fact that not all of the source code was in one giant heirarchy anymore (since everything was microservices and self-contained libraries it made sense to split them out).
After I left that company I ended up at a larger company (~14k employees) in part because I'd worked on SVN-to-Git migrations before. Definitely a different beast, since there were a huge amount of workflows that needed changing, importing 10 years of SVN history (some of which used to be CVS history), pruning out VM images and ISOs that had been inadvertently added, rewriting tons of code in their Jenkins instance, etc.
All this on top of installing, configuring, and managing a geographically distributed internal Gitlab instance with multiple repositories in the tens or hundreds of gigabytes.
It was a heck of a ride and took years, but it was a lot of fun at the same time. Thankfully 'the guy who suggested the transition' was the CEO (in the first company) or CTO (in the second) nothing went wrong, no one got thrown under buses, and both companies are still doing a-okay (as far as source control goes).
The way Git took over wasn't Git vs Mercurial (although that was a small part of it), but much more Git vs SVN, CVS, and people that never used source control before. It's similar to how Chrome became the dominant browser over Firefox. It was much more converts from Internet Explorer and Safari than advanced users that were already on Firefox.
That is an important point: in 2005 "all code must be in version control" was still a controversial idea, particularly for companies that made software but were not "tech" companies. A lot of git's expansion came from teams putting their software in a VCS for the first time.
The simple task of following a bug requires you to:
1. Send an empty email to a special address for the bug.
2. Wait 15-30 minutes for Debian's graylisting mail server to accept your email and reply with a confirmation email.
3. Reply to the confirmation email.
The last time I tried to follow a bug, I never got the confirmation email.
In practically every other bug tracker, following a bug is just pressing a button.
Like most of Debian's developer tooling, the bug tracker gets the job done (most of the time) but it's many times more inconvenient than it needs to be.
Fair points. But without looking at it myself, and for the benefit of people reading along, do you have to do that if you already have an account on the tracker? For instance, it's easy to follow issues on GitHub, but that's after you've jumped through some similar hoops to create an account.
I really wish we could have both. An interactive web frontend, and the classic email-centric bug tracker, both serving the same data. I think both have its strengths. I suppose that the job is massive given how enormous and fast-moving the first have become.
As someone who uses Debian and very occasionally interacts with the BTS, what I can say is this:
As far as I know, it is impossible to use the BTS without getting spammed, because the only way to interact with it is via email, and every interaction with the BTS is published without redaction on the web. So, if you ever hope to receive updates, or want to monitor a bug, you are also going to get spam.
Again, because of the email-only design, one must memorise commands or reference a text file to take actions on bugs. This may be decent for power users but it’s a horrible UX for most people. I can only assume that there is some analogue to the `bugreport` command I don’t know of for maintainers that actually offers some amount of UI assistance. As a user, I have no idea how to close my own bugs, or even to know which bugs I’ve created, so the burden falls entirely on the package maintainers to do all the work of keeping the bug tracker tidy (something that developers famously love to do…).
The search/bug view also does not work particularly well in my experience. The way that bugs are organised is totally unintuitive if you don’t already understand how it works. Part of this is a more general issue for all distributions of “which package is actually responsible for this bug?”, but Debian BTS is uniquely bad in my experience. It shows a combination of status and priority states and uses confusing symbols like “(frowning face which HN does not allow)” and “=” and “i” where you have to look at the tooltip just to know what the fuck that means.
> As far as I know, it is impossible to use the BTS without getting spammed, because the only way to interact with it is via email, and every interaction with the BTS is published without redaction on the web. So, if you ever hope to receive updates, or want to monitor a bug, you are also going to get spam.
Do the emails from the BTS come from a consistent source? If so, it's not a good solution, but you could sign up with a unique alias that blackholes anything that isn't from the BTS.
There is some nuance to this. Adding comments to the stated goal "Everyone who interacts with Debian source code (1) should be able to do so (2) entirely in git:
(1) should be able does not imply must, people are free to continue to use whatever tools they see fit
(2) Most of Debian work is of course already git-based, via Salsa [1], Debian's self-hosted GitLab instance. This is more about what is stored in git, how it relates to a source package (= what .debs are built from). For example, currently most Debian git repositories base their work in "pristine-tar" branches built from upstream tarball releases, rather than using upstream branches directly.
[1]: https://salsa.debian.org
If "whatever tools they see fit" means "patch quilting" then please no. Leave the stone age and enter the age of modern DVCS.
git can be seen as porcelain on top of patch quilting so it's not as much done âge as one might think
This is a misunderstanding of what Git does. Git is a Merkle hash tree, content-addressed, immutable/append-only filesystem, with commits as objects that bind a filesystem root by its hash. The diffs that make up a commit are not really its contents -- they are computed as needed. Now most of the time it's best to think of Git as a patch quilting porcelain, but it's really more than that, and while you can get very far with the patch quilting porcelain model, at some point you need to understand that it goes deeper.
The whole patch quilting thing is awful. Just keep the patches as commits. It won't "trick" me or anyone else, especially if you keep them in branches that denote "debian".
Please, please, stop the nonsense with the patch quilting -- it's really cumbersome, it adds unnecessary cognitive load, it raises the bar to contributions, it makes maintenance harder, and it adds _zero value_. Patch quilting is a lose-lose proposition.
> The whole patch quilting thing is awful. Just keep the patches as commits.
I'd say that `quilt` the utility is pretty much abandoned at this point. The name `quilt` remains in the format name, but otherwise is not relevant.
Nowadays people that maintain patches do it via `gbp-pq` (the "patch queue" subcommand of the badly named `git-buildpackage` software). `gbp-pq switch` reads the patches stored in `debian/patches/`, creates an ephemeral branch on top of the HEAD, and replays them there. Any change done to this branch (new commits, removed comments, amended commits) are transformed by `gbp-pq export` into a valid set of patches that replaces `debian/patches/`.
This mechanism introduces two extra commands (one to "enter" and one to "exit" the patch-applied view) but it allows Debian to easily maintain a mergeable Git repo with floating patches on top of the upstream sources. That's impossible to do with plain Git and needs extra tools or special workflows even outside of Debian.
What siblings say. What you want is `git rebase`, especially with the `--onto` and `--interactive` options. You might also want something like bisect-rebase.sh[0], though there are several other things like it now.
[0] https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...
> That's impossible to do with plain Git and needs extra tools or special workflows even outside of Debian
Rebase.
That’s what git-rebase is for, and it is built into standard git.
Moving from a patch stack maintained by quilt to git is what this article is about.
It's worth mentioning the quilting approach likely predates the advent of git by at least a decade.. I think compatibility with git has been available for a while now and I assume there was always something more pressing than migrating the base stack to git
dgit handles the whole affair with very little fuss I've found and is quite a pleasant workflow.
What is dgit?
https://wiki.debian.org/DgitFAQ
> 4. No-one should have to learn about Debian Source Packages, which are bizarre, and have been obsoleted by modern version control.
What is patch quilting, for the blissfully unaware?
https://wiki.debian.org/UsingQuilt but the short form is that you keep the original sources untouched, then as part of building the package, you apply everything in a `debian/patches` directory, do the build, and then revert them. Sort of an extreme version of "clearly labelled changes" - but tedious to work with since you need to apply, change and test, then stuff the changes back into diff form (the quilt tool uses a push/pop mechanism, so this isn't entirely mad.)
Ha yes that does sound mad. If only there was a version control system specifically designed to track changes to code...
Quilt predates Git. Back then source was distributed as a tarball, and Debian simply maintained a directory full of patches to apply to the tarball.
it's quite difficult to maintain a quilt like workflow with plain git
I've tried it
Quilt is difficult to maintain, but a quilt-like workflow? Easy: it's just a branch with all patches as commits. You can re-apply those to new releases of the upstream by using `git rebase --onto $new_upstream_commit_tag_or_branch`.
Oh, yes. This seems like nothing short of necessary for the long term viability of the project. I really hope this effort succeeds, thank you to everyone pushing this!
You might think, but here we are at the end of 2025 and this is still a WIP.
I don’t think it’s a bad move, but it also seems like they were getting by with patches and tarballs.
I can't find it now but I recently saw a graph of new Debian Developers joining the project over time and it has sharply declined in recent years. I was on track to becoming a Debian Developer (attended a couple DebConfs, got some packages into the archive, became a Debian Maintainer) but I ultimately burned out in large part because of how painful Debian's tooling makes everything. Michael Stapelberg's post about leaving Debian really rings true: https://michael.stapelberg.ch/posts/2019-03-10-debian-windin...
Debian may still be "getting by" but if they don't make changes like this Git transition they will eventually stop getting by.
What I've always found off-putting about the Debian packaging system is that the source lives with the packaging. I find that I prefer Ports-like systems where the packaging specifies where to fetch the source from. I find that when the source is included with the packaging, it feels more unwieldy. It also makes updating the package clumsier, because the packager has to replace the embedded source, rather than just changing which source tarball is fetched in the build recipe.
Debian requires that packages be able to be built entirely offline.
> Debian guarantees every binary package can be built from the available source packages for licensing and security reasons. For example, if your build system downloaded dependencies from an external site, the owner of the project could release a new version of that dependency with a different license. An attacker could even serve a malicious version of the dependency when the request comes from Debian's build servers. [1]
[1] https://wiki.debian.org/UpstreamGuide#:~:text=make%20V=1-,Su...
So do Gentoo and Nix, yet they have packaging separate from the source code. The source is fetched, but the build is sandboxed from the network during the configure, build and install phases. So it's technically possible.
Nix definitely does not allow most things to be built offline (at least in the way Debian means it).
With Nix, any fetcher will download the source. It does so in a way that guarantees the shasum of what is fetched is identical, and if you already have something in the nix store with that shasum, it won't have to fetch it.
However, with just a mirror of the debian source tree, you can build everything without hitting the internet. This is assuredly not true with just a mirror of nixpkgs.
There are probably still ways to maintain a source archive with a ports system. Just analyze the sources used by builds, create a mirror, and redirect fetches to use the mirror. It's not that crazy. The packaging would still be a separate affair.
> With Nix, any fetcher will download the source.
OK, I see how the Debian idea differs from the Portage/Nix/etc. idea. For Portage and Nix it is enough that the build proper be offline, but the source code is fetched at the beginning of the package build. Not only do I find this sufficient, I prefer it because IMO it makes the package easier to work with (since you're only wrangling the packaging code, not upstream's).
Nix and specifically nixpkgs is IMO very bad at this. It's not a distro: it's a collection of random links that in many cases now only exists in cache.nixos.org. The tarball server frequently doesn't have content, can't represent some content at all (recursive hash types), links have rotted away completely (broadcom driver zips referencing a domain which is now advertising online gambling).
Nix isn't functional: it's a functional core that moved every bit of the imperative part to an even less parseable stage, labelled it "evaluation" and then ignored any sense of hygiene about it.
No: your dependency tree for packaging should absolutely not include an opaque binary from a cache server, or a link to a years old patch posted on someone else's bugzilla instance (frequently link rotted as well).
Nothing has made me appreciate the decisions of mainstream distributions more then dealing with an alternative like this.
that's a pretty damning detail about nix which everyone else seems to speak so highly about. are there any articles that explain this in more detail?
All that is required for this to work (building offline) and be immune to all bad thing you wrote: package build part must contain checksum of source code archive and mirror that source code.
This doesn't say what you think it does. It says that every binary package should only depend on its declared source packages. It does not say that source packages must be constructed without an upstream connection.
What the OP was referring to, is that Debian's tooling stores the upstream code along with the debian build code. There is support tooling for downloading new upstream versions (uscan) and for incorporating the upstream changes into Debian's version control (uupdate) to manage this complexity, but it does mean that Debian effectively mirrors the upstream code twice: in its source management system (mostly salsa.debian.org nowadays), and in its archive, as Debian source archives.
This is such a wonderful guarantee to offer to users. In most cases, I trust the Debian maintainers more than a trust the upstream devs (especially once you take into account supply chain attacks).
It's sad how much Linux stuff is moving away from apt to systems like snap and flatpak that ship directly from upstream.
> What I've always found off-putting about the Debian packaging system is that the source lives with the packaging.
Many packages have stopped shipping the whole source and just keep the debian directory in Git.
Notable examples are
- gcc-*
- openjdk-*
- llvm-toolchain-*
and many more.
But isn't that incompatible with the proposed transition to Git?
It made a lot of sense before centralized source storage (Debian packaging predates Sourceforge, let alone github).
But it's still nice to have when an upstream source goes dark unexpectedly, as does occasionally still happen.
> I find that when the source is included with the packaging, it feels more unwieldy.
On the other hand, it makes for a far easier life when bumping compile or run time dependency versions. There's only one single source of truth providing both the application and the packaging.
It's just the same with Docker and Helm charts. So many projects insist on keeping sometimes all of them in different repositories, making change proposals an utter PITA.
Correct me if I’m wrong but as I’m understanding it, the processes is well underway towards moving the core systems and libraries (or whatever it’s all called) across to the new way. But that there’s a massive job of extended libraries maintained by lots of other parties and this ecosystem of libraries have been using all manner of approaches, each of which has its drawbacks and the big goal here is to get all these maintainers onboard to switch over to the new git-based workflow that this transition team (and others) have been working hard to make logical and easy enough to implement.
Is that a fair general read of the situation? (I have further comments to make but wanted to check my basic assumptions first).
Now if a consequence of that could be that one (as an author of a piece of not-yet-debianized software) can have the possibility to decently build Debian packages out of their own repository and, once the package is qualified to be included in Debian, trivially get the publish process working, that would be a godsend.
At the moment, it is nothing but pain if one is not already accustomed and used to building Debian packages to even get a local build of a package working.
The problem is that "once the package is qualified to be included in Debian" is _mostly_ about "has the package metadata been filled in correctly" and the fact that all your build dependencies also need to be in Debian already.
If you want a "simple custom repository" you likely want to go in a different direction and explicitly do things that wouldn't be allowed in the official Debian repositories.
For example, dynamic linking is easy when you only support a single Debian release, or when the Debian build/pkg infrastructure handles this for you, but if you run a custom repository you either need a package for each Debian release you care about and have an understanding of things like `~deb13u1` to make sure your upgrade paths work correctly, or use static binaries (which is what I do for my custom repository).
They could take a look at how pkgsrc [1] works.
[1] https://www.pkgsrc.org/
pkgsrc is great, I use this on smartos (as just an end user) and it’s extremely straightforward
> The canonical git format is “patches applied”.
How many Debian packages have patches applied to upstream?
Most, because Debian is the only distro which strictly enforces their manpages and filesystem standards. And most source packages don't care much, resp. have other ideas
Lots. Because many upstream projects don't have their build system set up to work within a distribution (to get dependencies form the system and to install to standard places). All distros must patch things to get them to work.
Well, there are big differences in how aggressively things are patched. Arch Linux makes a point to strictly minimize patches and avoid them entirely whenever possible. That's a good thing, because otherwise, nonsense like the Xscreensaver situation ensues, where the original developers aggressively reject distro packages for mutilating their work and/or forcing old and buggy versions on unsuspecting users.
> nonsense like the Xscreensaver situation ensues, where the original developers aggressively reject distro packages
I didn't know about this. Link?
Huh? I contribute to Debian; I don't aggressively patch anything. You can too.
It's "let's patch as little as possible" vs "let's enforce our rules with the smallest patch possible"
A fair few I expect, amongst actively developed apps/utils/libs. Away from sid (unstable) Debian packages are often a bit behind upstream but still supported, so security fixes are often back-ported if the upstream project isn't also maintaining older releases that happen to match the version(s) in testing/stable/oldstable.
https://archive.ph/vp6rp
I always thought that Debian is already on git, so this confused me. How is source control currently (or was) done with the Debian project?
The short answer is that it's not.
The longer answer is that a lot of people already use Git for Debian version control, and the article expands on how this will be better-integrated in the future. But what goes into the archive (for building) is fundamentally just a source package with a version number. There's a changelog, but you're free to lie in it if you so wish.
Debian is kind of slow in adapting to the modern world.
I kind of appreciate that debian put FOSS at a core value very early on; in fact, it was the first distribution I used that forced me to learn the commandline. The xorg-server or rather X11 server back then was not working so I only had the commandline, and a lean debian handbook. I typed in the commands and learned from that. Before this I had SUSE and it had a much thicker book, with a fancypants GUI - and it was utterly useless. But that was in 2005 or so.
Now, in 2025, I have not used debian or any debian based distribution in a long time. I either compile from source loosely inspired by LFS/BLFS; or I may use Manjaro typically these days, simply because it is the closest to a modern slackware variant (despite systemd; slackware I used for a long time, but sadly it slowed down too much in the last 10 years, even with modern variants such as alienbob's slackware variant - manjaro moves forward like 100x faster and it also works at the same time, including when I want to compile from source; for some reason, many older distributions failed to adapt to the modern era. Systemd may be one barrier here, but the issue is much more fundamental than that. For instance, you have many more packages now, and many things take longer to compile, e. g. LLVM and what not, which in turn is needed for mesa, then we have cmake, meson/ninja and so forth. A lot more software to handle nowadays).
> Debian is kind of slow in adapting to the modern world.
Yeah definitely. I guess this is a result of their weird idea that they have to own the entire world. Every bit of open source Linux software ever made must be in Debian.
If you have to upgrade the entire world it's going to take a while...
This is great; I hate fighting distro source tools when I want to debug something.
This just adds a new tool though.
Obligatory XKCD reference: https://xkcd.com/927/
New tools during the transition, hopefully fewer tools in the long run. Also things making a lot more sense in the long run.
I remember when a startup I used to work for made the transition from svn to git. They transitioned, then threw the guy who suggested the transition under the bus; he quit, and then the company collapsed. Lol!
I was hired at a small startup (~15 employees total) and one of the first things I did was to migrate their SVN repository to Git. Not too difficult, brought over the history and then had to write a bunch of tooling to handle the fact that not all of the source code was in one giant heirarchy anymore (since everything was microservices and self-contained libraries it made sense to split them out).
After I left that company I ended up at a larger company (~14k employees) in part because I'd worked on SVN-to-Git migrations before. Definitely a different beast, since there were a huge amount of workflows that needed changing, importing 10 years of SVN history (some of which used to be CVS history), pruning out VM images and ISOs that had been inadvertently added, rewriting tons of code in their Jenkins instance, etc.
All this on top of installing, configuring, and managing a geographically distributed internal Gitlab instance with multiple repositories in the tens or hundreds of gigabytes.
It was a heck of a ride and took years, but it was a lot of fun at the same time. Thankfully 'the guy who suggested the transition' was the CEO (in the first company) or CTO (in the second) nothing went wrong, no one got thrown under buses, and both companies are still doing a-okay (as far as source control goes).
git is a skill check on learning tools to get a job done
git is actually a case-study in "Worse Is Better". hg beats it in every way, except pure speed. Of course, git is still way better than svn, tho.
The way Git took over wasn't Git vs Mercurial (although that was a small part of it), but much more Git vs SVN, CVS, and people that never used source control before. It's similar to how Chrome became the dominant browser over Firefox. It was much more converts from Internet Explorer and Safari than advanced users that were already on Firefox.
That is an important point: in 2005 "all code must be in version control" was still a controversial idea, particularly for companies that made software but were not "tech" companies. A lot of git's expansion came from teams putting their software in a VCS for the first time.
I wish Debian would also transition to a modern bug tracker. Current one is very archaic.
It surely won't win any beauty contests, but do you think it's missing any needed functionality?
Sincere question. I haven't interacted with it much in ages.
The simple task of following a bug requires you to:
1. Send an empty email to a special address for the bug.
2. Wait 15-30 minutes for Debian's graylisting mail server to accept your email and reply with a confirmation email.
3. Reply to the confirmation email.
The last time I tried to follow a bug, I never got the confirmation email.
In practically every other bug tracker, following a bug is just pressing a button.
Like most of Debian's developer tooling, the bug tracker gets the job done (most of the time) but it's many times more inconvenient than it needs to be.
Fair points. But without looking at it myself, and for the benefit of people reading along, do you have to do that if you already have an account on the tracker? For instance, it's easy to follow issues on GitHub, but that's after you've jumped through some similar hoops to create an account.
There is no way to create an account for the Debian bug tracker. You have to jump through these hoops every single time you want to follow a bug.
Oh, wow. Yeah. Well, I asked, and now I know!
I really wish we could have both. An interactive web frontend, and the classic email-centric bug tracker, both serving the same data. I think both have its strengths. I suppose that the job is massive given how enormous and fast-moving the first have become.
Yeah but virtually every developer in the world has already jumped through that hoop. They don't need to do it again for every project.
Also the hoop can be as simple as "click here to sign in with <other account you already have>".
I use reportbug to simplify the process of initial reporting, but whole interaction is still far from convenient.
https://tracker.debian.org/pkg/reportbug
As someone who uses Debian and very occasionally interacts with the BTS, what I can say is this:
As far as I know, it is impossible to use the BTS without getting spammed, because the only way to interact with it is via email, and every interaction with the BTS is published without redaction on the web. So, if you ever hope to receive updates, or want to monitor a bug, you are also going to get spam.
Again, because of the email-only design, one must memorise commands or reference a text file to take actions on bugs. This may be decent for power users but it’s a horrible UX for most people. I can only assume that there is some analogue to the `bugreport` command I don’t know of for maintainers that actually offers some amount of UI assistance. As a user, I have no idea how to close my own bugs, or even to know which bugs I’ve created, so the burden falls entirely on the package maintainers to do all the work of keeping the bug tracker tidy (something that developers famously love to do…).
The search/bug view also does not work particularly well in my experience. The way that bugs are organised is totally unintuitive if you don’t already understand how it works. Part of this is a more general issue for all distributions of “which package is actually responsible for this bug?”, but Debian BTS is uniquely bad in my experience. It shows a combination of status and priority states and uses confusing symbols like “(frowning face which HN does not allow)” and “=” and “i” where you have to look at the tooltip just to know what the fuck that means.
> As far as I know, it is impossible to use the BTS without getting spammed, because the only way to interact with it is via email, and every interaction with the BTS is published without redaction on the web. So, if you ever hope to receive updates, or want to monitor a bug, you are also going to get spam.
Do the emails from the BTS come from a consistent source? If so, it's not a good solution, but you could sign up with a unique alias that blackholes anything that isn't from the BTS.
The command is `bts` in devscripts. I wrote it in 2001.
It's just annoyingly clunky to use any time I need to interact with it, versus modern bug trackers like GitLab's and etc.
Also, locally patching reportbug to support XDG base directory spec is a chore (since maintainers didn't accept the fix for it for years).
to be fair, it fits my exact needs. and without common javacript bloat.
so kudos to its authors
Ian Jackson (the author of this article) also wrote debbugs.