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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEV6G/FbT2+ZuJ7bKf05SBrh55rPcFAma7RNsACgkQ05SBrh55 rPdX4Q//eKMr1FQzwZWuIYOSQodpKMEQbY3RpP5GWrmvx1+Y6zWOn6sA/iyystzu iDKu3Btgl5m8cu4TGNMm1jHXSiMEsJp9Fd705Y2jWasDjqyj9GFLMkkaUmQZPbBr yTd9jPLUpiOhIUVBdc84BVi2rIhDeSvV4ne5ujAeLt7oV6Kg9l7b4ZHtiu2NZ2Xs 0Tame2rIQd8ruragFGrytVQbJfFDIEl8HY1so4/ojvd92AMEBkjum05dbHUaJojI VPG7KptpUD/pUDAPej47NYA4glKJk4xQOeYRdSDHznDuI2dGgqIytfvzkZ9t2yac YZA4LAtFpYZc6stx7//ru85geF9rV+xqRYFb822TR+wsLERy9ktp/Qrhp5HnDb97 AcT4ZuRXvgtKmgcYBDfDg0W6YK5e8Da5YRAajFMAY/UC3Fwwd0zjNbLHPE0Orc5G PkmlbDmzQhwSnSuiBkWgLNHGpV/TLguXRjWe/mReo1fybiwi3s6biDDKRo3pVZ/X qxYOanCqKxFuOWWfZM1lnFBgD/q08Qo0a8zMOUeiBpEVcmH6Q/Ny6HFFJANkI6K8 dtfgXw4TpNko9al0LIpMaDnGYIANiT/6AOrg3DLhd00M4ty2IpxUD5ew82WlAqGu PQi+ODd5VC1OUPPCoZAxfUVaKWLZjJyGKrDFoM0u4PFDVLEK1Qk=
=gYp2
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)