Distribution quote of the week

[Posted August 18, 2021 by ris]

For example, there are those of us who think that the downsides of the combination of 3.0 (quilt) and patches stored unapplied in git are significant, and so we have made attempts to provide alternatives, such as git-debrebase. Contributing to Debian would be a lot less fun if we were asked to just set these reasons aside and use something which to us is clearly technically inferior.

— Sean Whitton

Distribution quote of the week

Posted Aug 19, 2021 1:36 UTC (Thu) by jkingweb (subscriber, #113039) [Link] (6 responses)

As someone who's recently struggled with his first experience in Debian packaging, I'd love to know what...

> the downsides of the combination of 3.0 (quilt) and patches stored unapplied in git

... are. I don't think I know enough about the ins and outs of Debian packaging to understand fully the argument being made.

Debian packaging

Posted Aug 19, 2021 10:01 UTC (Thu) by smurf (subscriber, #17840) [Link] (4 responses)

Well, storing unapplied patches in quilt+git means

* it runs contrary to the normal git workflow which is to create a branch, change things (or apply patches) there, build your deliverables from that, and be done with it. So for quilt you need to remember how to use a bunch of Debian-specific tools to manage non-Debian-specific work
* … which is doubly annoying when your primary mission is to fix (or import the existing fix for) an upstream bug, and fixing your local Debian package, while kindof required, is secondary
* when you update a patch, the resulting diff is well nigh unreadable
* the source you're building is not "git clean" so if upstream code gets the current version from git because, hey, this is the 2020s and maintainer time is a scarce resource, thus making a release should require "git tag && git push" instead of manually replacing the current version number in N source files, it will complain and/or append "-dirty" to its version, which is ugly.
* it's also annoying from a reproducibility / verifiability PoV because now the de-quilter is part of the toolchain: you need to examine the build logs to check which patches have been applied, instead of just looking at the tagged git tree and verifying the contents of the patched file there.

I'm a Debian Developer, but I'm mostly retired because IMHO Debian's refusal to settle on one single standard workflow for packaging is far too tedious to deal with on a daily basis. For me, anyway. YMMV.

My standard workflow when I need to work on quilted Debian packages is *always*

* get upstream git archive
* create a work branch, off the latest release
* get Debian packaging from the archive, read debian/patches/series, apply patches one by one
* create a Debian branch from that
* check in debian/ subdirectory, without debian/patches
* return to work branch
* package ready? run a script that tags the work branch, merges it to the Debian branch, pushes the result to my local builder, and returns to the work branch
* never manually touch the Debian branch (unless of course there are packaging issues)

I never do a NMU. At most I'll file a bug and submit a patch that cleanly applies to my "work" or "deb" branch. Let the maintainer deal with the merging and packaging as they see fit, I'm not going to spend more time discovering how this or that package is managed than on the actual bugfix.

In my perfect world Debian would auto-convert every package's repository out there to adhere to this (or some similar) structure and have one single way of dealing with upstream source and their fixups. They're not, that's fine, their decision, but IMHO we're not in the 90s any more.

Debian packaging

Posted Aug 19, 2021 11:47 UTC (Thu) by jkingweb (subscriber, #113039) [Link]

Way more detail than I expected, and very helpful. Thanks!

Debian packaging

Posted Aug 20, 2021 22:08 UTC (Fri) by spwhitton (subscriber, #71678) [Link] (2 responses)

Have you tried 'dgit clone' yet? It's meant to get you something uniform and more git-friendly no matter what the package maintainer is doing.

Debian packaging

Posted Aug 22, 2021 10:56 UTC (Sun) by smurf (subscriber, #17840) [Link] (1 responses)

I know about dgit.

Problem is (a) it's yet another tool to learn and (b) worse, I want the (1) raw upstream git archive with (2) any Debian patches, then (3) the Debian packaging (_without_ any "debian/patches" subdirectory) on top of that.

"dgit" is more than likely to fail at (1), esp. when the "original" archive isn't but has been stripped from anything non-DFSG-free. Also, it first merges Debian packaging and then unravels debian/patches/series, while a sane upstream-able git tree is structured the other way round.

The Debian archive structure is from a world where there was no widely-available distributed VCS and source tarballs were required. Today? not so much.

I feed "archive location + commit ID" to my builder, from a post-commit hook, and expect it to build the binary packages and to push them to my archive. Done.

I do not want to futz around with collecting, assembling and uploading source packages. Doing that is not just superfluous – the whole ancient mechanism blocks further progress. IMHO it's beyond time for Debian to drop all that nonsense and switch to making "git push" the one and only way to update Debian source packages. You can simply run "dgit clone … && git push --force dgit/sid archive:sid" when somebody does a legacy source upload.

Debian packaging

Posted Aug 25, 2021 18:06 UTC (Wed) by spwhitton (subscriber, #71678) [Link]

There's nothing to learn other than 'dgit clone' unless you're trying to do uploads. It seems like we disagree about the specific ordering of commits that is most natural, but 'dgit clone' is really very close to what you describe, so I'd encourage you to take another look.

Distribution quote of the week

Posted Aug 20, 2021 22:07 UTC (Fri) by spwhitton (subscriber, #71678) [Link]

Here are a few of the issues:

- The git tree is not directly buildable because you have to apply the patches first to get the source code you actually want to build. This is not standard with git -- one commits the actual source code, not something which can become the actual source code -- and so confusing to those who are not already Debian specialists.

- The git tree is not the actual source code running on a system with the .deb installed; again, you have to apply the patches first. So for example if you just cloned and used 'git grep', you wouldn't be searching the code base you actually want to search.

- You can't apply upstream patches which might fix your problem just by typing 'git cherry-pick' and referring to upstream's branch. You have to do something Debian-specific and which takes you outside of ordinary git.

- You've effectively got one revision control system nested inside another, without the outer system (git) having much awareness of the inner system (quilt), so you get unpleasant merge conflicts etc. The Debian changes ought to be a series of commits, one per change, as they are with git-debrebase.