[HN Gopher] Debian's Git Transition
___________________________________________________________________
Debian's Git Transition
Author : all-along
Score : 178 points
Date : 2025-12-22 08:24 UTC (14 hours ago)
(HTM) web link (diziet.dreamwidth.org)
(TXT) w3m dump (diziet.dreamwidth.org)
| mschuster91 wrote:
| 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.
| rjsw wrote:
| They could take a look at how pkgsrc [1] works.
|
| [1] https://www.pkgsrc.org/
| eduction wrote:
| pkgsrc is great, I use this on smartos (as just an end user)
| and it's extremely straightforward
| kpcyrd wrote:
| 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).
| Valodim wrote:
| 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!
| jonhohle wrote:
| 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.
| agwa wrote:
| 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.
| hu3 wrote:
| https://archive.ph/vp6rp
| ckastner wrote:
| 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
| cryptonector wrote:
| If "whatever tools they see fit" means "patch quilting" then
| please no. Leave the stone age and enter the age of modern
| DVCS.
| lta wrote:
| git can be seen as porcelain on top of patch quilting so it's
| not as much done age as one might think
| shmerl wrote:
| I wish Debian would also transition to a modern bug tracker.
| Current one is very archaic.
| thesnide wrote:
| to be fair, it fits my exact needs. and without common
| javacript bloat.
|
| so kudos to its authors
| fanf2 wrote:
| Ian Jackson (the author of this article) also wrote debbugs.
| kstrauser wrote:
| 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.
| agwa wrote:
| 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.
| shmerl wrote:
| I use reportbug to simplify the process of initial
| reporting, but whole interaction is still far from
| convenient.
|
| https://tracker.debian.org/pkg/reportbug
| kstrauser wrote:
| 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.
| IshKebab wrote:
| 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>".
| gspr wrote:
| 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.
| agwa wrote:
| 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.
| shmerl wrote:
| 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).
| csnover wrote:
| 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.
| joeyh wrote:
| The command is `bts` in devscripts. I wrote it in 2001.
| jancsika wrote:
| > The canonical git format is "patches applied".
|
| How many Debian packages have patches applied to upstream?
| dspillett wrote:
| 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.
| dima55 wrote:
| 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.
| latchup wrote:
| 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.
| dima55 wrote:
| Huh? I contribute to Debian; I don't aggressively patch
| anything. You can too.
| lionkor wrote:
| It's "let's patch as little as possible" vs "let's
| enforce our rules with the smallest patch possible"
| rurban wrote:
| 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
| rilindo wrote:
| 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?
| Sesse__ wrote:
| 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.
| trebligdivad wrote:
| This is great; I hate fighting distro source tools when I want to
| debug something.
| throwaway7356 wrote:
| This just adds a new tool though.
|
| Obligatory XKCD reference: https://xkcd.com/927/
| MarsIronPI wrote:
| 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.
| sillystuff wrote:
| 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...
| MarsIronPI wrote:
| 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.
| aidenn0 wrote:
| 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.
| XorNot wrote:
| 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.
| 0x457 wrote:
| 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.
| tremon wrote:
| 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.
| cbmuser wrote:
| > 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.
| throwaway7356 wrote:
| But isn't that incompatible with the proposed transition to
| Git?
| mschuster91 wrote:
| > 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.
| shevy-java wrote:
| 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).
| IshKebab wrote:
| > 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...
| cryptonector wrote:
| 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.
| dima55 wrote:
| Moving from a patch stack maintained by quilt to git is what
| this article is about.
| IshKebab wrote:
| What is patch quilting, for the blissfully unaware?
| eichin wrote:
| 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.)
| IshKebab wrote:
| Ha yes that does sound mad. If only there was a version
| control system specifically designed to track changes to
| code...
| blibble wrote:
| it's quite difficult to maintain a quilt like workflow
| with plain git
|
| I've tried it
| lta wrote:
| 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
| XorNot wrote:
| dgit handles the whole affair with very little fuss I've
| found and is quite a pleasant workflow.
| m463 wrote:
| > 4. No-one should have to learn about Debian Source Packages,
| which are bizarre, and have been obsoleted by modern version
| control.
| gioele wrote:
| > 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.
| coryrc wrote:
| > That's impossible to do with plain Git and needs extra
| tools or special workflows even outside of Debian
|
| Rebase.
| evolve2k wrote:
| 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).
| djaouen wrote:
| 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!
| lionkor wrote:
| git is a skill check on learning tools to get a job done
___________________________________________________________________
(page generated 2025-12-22 23:00 UTC)