#Debian 's git transition

blog post, by me: https://diziet.dreamwidth.org/20436.html

tl;dr:

There is a Debian git transition plan. It’s going OK so far but we need help, especially with outreach and updating Debian’s documentation.

@Diziet as someone who disengaged with Debian maintainership over the friction of the tooling: thank you so much for working on this! Improving the Debian developer workflow is long overdue!

@Diziet thank you for doing this. It is difficult, important, and appreciated.

@Diziet Uhh, this is flawed? Using Git this way means that you are no longer distributing and mirroring source archives alongside binary artifacts. Without that, you're violating at least every GNU family license.

(And also as an upstream software developer with software packaged in Debian, I am super not a fan of Debian's approach of mangling packaging data into source code. I really wish they'd change how the source packaging model worked to firmly split it.)

@neal @Diziet Is your claim that GNU licenses require that source be distributed as a tarball? That is surely not the case. GPL3 (for example) explicitly envisages source code and object code being available in different locations (providing it is clear how to find the relevant source).

But perhaps I have misunderstood your objection.

@demoographics @Diziet No. My objection is that the transition is being done without considering why automatic redistribution of sources alongside binaries is important for compliance. The "git transition plan" basically kills redistribution of sources with binaries, and I think that's too important to lose.

@neal @demoographics Did you miss where I wrote "Certainly source packages are going to continue to be supported for the foreseeable future"? There is no plan to stop shipping dscs any time soon; they will be needed for technical compatibility with legacy downstream tooling, if nothing else.

So we can cross this bridge when we come to it. (Spoiler: I don't agree with your interpretation of the GPLs. Saying we "didn't consider" this question is quite rude.)

@Diziet @demoographics I did not miss it, but it's clear from everything else in the post that the intent is to kill it.

@neal @Diziet GPLv2 section 3.b) clearly describes a permitted approach which is not "distributing and mirroring source archives alongside binary artifacts", just off the top of my head.

@denisbloodnok @Diziet Yes, I'm aware. But getting mirrors and redistributors to be capable of doing that is the challenging part. It's much easier to just avoid that problem altogether.

@neal, I think you misunderstand how Debian packaging works. The packaging data is absolutely NOT mangled into the source code. The original source code is always shipped separately from the Debian packaging. Always has been. (Apart from so-called "native" packages which are for packages not having any meaningful upstream outside of Debian.)

@andrew_shadura I don't misunderstand how it works. The "debianization" process with tools like `git-buildpackage` make it so the `debian/` folder is merged into the source code when importing into Git. It's rare that I see a package that just has the repo only contain the `debian/` folder and the pristine-tar refs instead of a full mangle alongside the other refs.

@neal, well, your understanding is incorrect. This representatiom only exists in the working directory of an unpacked source package. The package itself clearly separates upstream source and the Debian delta.

@neal and even in Git workflows, the upstream source is always on a separate branch, with Debian overlay applied only on the Debian branch. There is no mangling: it's only debian/ directory.

@neal in any case, at the level of the source package, the separation always exists.

@andrew_shadura That is definitely not how it looks. It is *not* clearly separated.

Compare these two:
- https://salsa.debian.org/games-team/lugaru
- https://salsa.debian.org/kernel-team/linux

The first one has packaging mangled with sources, and the second one is purely packaging.

@neal that's a packaging Git repository, not the source package itself.

@andrew_shadura Yes, but it doesn't need to exist this way at all, and I think it shouldn't. But the default in Debian is to do this. I wish Debian didn't, and instead defaulted to the way the Linux kernel packaging and KDE stack packaging are done.

@neal, based on what you said I can see you don't fully understand the idea of how packaging works in Debian.
Unfortunately, it's too late here for me to explain these concepts to you, so you'll have to do your homework yourself.
Please don't criticise what you don't fully understand.

@andrew_shadura Please stop assuming I don't understand it. I've packaged software the Debian way before. I'm aware of the triple-ref system, and I know how there's an "upstream", a "pristine-tar", and the "debian" branch.

I sincerely believe that packaging style encourages terrible habits, since it confuses the nature of pristine sources with packaging sources.

@neal same as you can use git for years without understanding it's data model, you can create packages without fully understanding the details. Triple refs are irrelevant. What's important, in short, that there are two representations of the package, packed and unpacked, and the tarball is always part of it, which is what makes the lossless transformation between the two forms possible, cleanly separating the upstream code and the packaging.

@neal If you were aware of that then it seems curious to have written "you are no longer distributing and mirroring source archives alongside binary artifacts. Without that, you're violating at least every GNU family license", since what you wrote would have been obviously untrue at the time you wrote it.

@denisbloodnok It is not untrue as currently mirrors and redistributors do nothing, so if source packages start disappearing, *they* would no longer be complying with the licenses. There's no offer, no sources, and no defined way to rectify the problem.

@neal Your original text did not make that distinction, so no, it was untrue; and it would be perfectly practical to avoid difficulty here by, for example, ensuring the offer is in a plaintext file in the Debian binary package, which is adequate for noncommercial redistribution (which is the vast majority of mirror activity these days).

@jmtd @andrew_shadura Yes. I've worked with Debian packaging in both the SVN and early Git eras. And when gbp started getting adopted, I've used it too.

However, I'm very much for a model where there's a firm split because it makes it clear what is yours and what is upstream's.

The `dgit` model basically moves fully over to merged-source and no longer represents patches in the `debian/`. In effect, it makes every package operate as `3.0 (native)` even if it's a quilted package.

@jmtd @andrew_shadura My problem with this is that it ultimately winds up disguising the differences and eases the tendency to disengage from upstream because it becomes *too* easy to maintain patches.

I've seen this pattern repeat in other projects, and it just results in huge piles of tech debt that nobody can pay and nobody is willing to declare bankruptcy on.

@Diziet A dgit question that I've been unable to find answers to online: if you have a dgit clone with local changes and the distro releases a new update to the package, you 'dgit pull' and then ... how does dgit react? Do your changes get rebased, or do you get thrown into a git merge? Is there a way to control this?

(It might also be nice if dgit added a local tag for every upstream version it imports. You can get this information from logs, but...)

@cks dgit pull is like git pull, so merge. You can dgit fetch & then rebase or whatever you like

@Diziet Thank you. I'll have to remember that for dgit usage (which I'm probably going to use from now onward, it's so much better for local changes for all the usual git versions and then some). It might be worth an explicit note about this in the dgit manpage; as a (Debian/Ubuntu) packaging outsider, the behavior wasn't obvious to me.

@jmtd @andrew_shadura For what it's worth, this is also my complaint with various equivalent approaches that are done for some CentOS/Fedora packages and openSUSE packages.

It has also introduced the problem Debian also has where the canonicity of the packaging is no longer in the distribution shared SCM, which locks out community contributors and forces everyone to depend on the maintainers who have access to that SCM for fixes.