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 It works well for NMUs, even without access to package repository at all, and IMHO it is a relief when one does not need to bother with "gbp import-orig" or other methods of committing upstream sources. (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.) > so I > have a hard time recommending something. gbp is the most popular but I find > it lacking in a number of technical aspects. dgit is nice but complex, > still a bit niche and also not technically perfect in my eyes. 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". Here is some criticism: https://salsa.debian.org/onlyjob/notes/-/wikis/no-gbp > Perhaps it would be best to just stick with the current debian/-only repo > layout since blktrace doesn't seem to get many releases anyway? Yes, absolutely. > 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. (Alternatively just extract tarball, copy/add "debian" folder and build.) -- All the best, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- If you make a mistake and do not correct it, this is called a mistake. -- Anonymous, "Analects"
Attachment:
signature.asc
Description: This is a digitally signed message part.