On 8/13/24 04:34, Daniel Gröber wrote:
On Mon, Aug 12, 2024 at 11:37:24PM +1000, Dmitry Smirnov wrote:
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.
I haven’t followed the gbp discussion closely, but as a package
maintainer who does not know Debian thoroughly I found all documented
workflows except gbp near incomprehensible. This is not to say they are
poorly founded or documented, but rather that they did not fit my
intuitions. gbp on the other hand seemed to “just work”. The criticisms
on the wiki seem to assume you’re importing a tarball, whereas I was
starting from an upstream already in git (I am also the upstream
maintainer). The ease of gbp to people like me is that we already know
git well, but do not know Debian well.
