On Mon, Aug 12, 2024 at 11:37:24PM +1000, Dmitry Smirnov wrote: > On Sunday, 11 August 2024 8:51:06 PM AEST Daniel Gröber wrote: > > What remains to discuss is how you want to handle the git repo. Personally > > I still haven't found a git packaging workflow I'm really happy with > > I use something like the following that does not depend on git, GBP, etc.: > > https://salsa.debian.org/onlyjob/notes/-/wikis/bp
Yeah, that doesn't work for me. I get anxious without a git repo :) Since I'm still searching here's my git workflow requirements list: - patches-applied (just commit/cherry-pick, no manual debian/patches handling) - utilizes git-rebase (I want magit integration) - allows preserving upstream history - "import" upstream releases from git > (By the way GBP workflow is a huge impediment for large packages, MUT > packages, as well as packages with many vendored/bundled libraries which > is typical for Golang software.) > IMHO GBP approach is counter-productive, with needlessly complicated > workflow, redundant upstream branch(es) and incredibly inconvenient merge > of debian packaging and upstream files in "master". I agree in principle but my solution does not involve giving up on git packaging tools entirely :) > Here is some criticism: > > https://salsa.debian.org/onlyjob/notes/-/wikis/no-gbp Thanks for putting that together. I always struggle to articulate, in detail, the many ways that gbp is a terrible workflow :) However: I think your criticism on space/bandwith use is unfounded. Git is spectacularly efficient at packing history. Even when it isn't because there's just so much of it --depth=N is always there to only download a compressed tarball's equivalent of data but with git benefits. I'd also like to point out that git is more useful for bandwidth constraint users because it does delta-transfers. Imagine downloading multiple versions of 0ad-data to do some archaeology. > > If we document the magic incantation to unpack a new upstream release > > in d/README.source it's not so bad really. > > There is not much to document, as "origtargz" is all that one needs. > And arguably that should be a common knowledge among Debian maintainers. It's more complicated than that. Please don't assume "common knowledge", onboarding new contributors into Debian is immensly difficult because there so much "common knowledge" that's assumed. (Ask me how I know :) IMO every workflow should have documentation like dgit's dgit-maint-* manpages even when it's "trivial". Any one workflow may be, but Debian has *many* of them. Before I started my DM/DD journey, i.e. "from the outside", it very much looked like gbp was just the thing to do now. Many prominent packages use it after all. IMO if alternate workflows want to have any success they need to be visible. --Daniel
signature.asc
Description: PGP signature
