Hi Daniel, please forgive me for brief, blunt, and perhaps somewhat irritated reply. On Tuesday, 13 August 2024 9:34:54 PM AEST Daniel Gröber wrote: > > https://salsa.debian.org/onlyjob/notes/-/wikis/bp > > Yeah, that doesn't work for me. I get anxious without a git repo :) In the end simplest and most straightforward approach works the best. Use git repo, but don't rely on it to build a package. You can build in dedicated build directory, and that don't have to be the debian package repository. > Since I'm still searching here's my git workflow requirements list: Overly complicated workflow is impediment for collaboration and co-maintenance. Simple is really the better. The less distraction on packaging tools will give you more capacity to focus on problems that need solving. > - patches-applied (just commit/cherry-pick, no manual debian/patches > handling) There is no way to avoid manual handling of patches. Exporting git commit as a patch is trivial enough. "quilt" may be not the most advanced patch management system, but it is certainly quite robust. > - allows preserving upstream history Get upstream history from upstream. More often than not you won't need upstream history, and certainly there is no need to mirror it on debian infrastructure. It is most inconvenient when upstream history is interleaved with debian package history. Keeping them apart is the best. > - "import" upstream releases from git That is the most awful thing about GBP workflow. Sometimes it is not applicable, sometimes it does not work, when it works it works badly, it comes with significant overhead plus risks of inconsistencies. Many problems originate from storing upstream in debian packaging repo. It is almost always redundant. As maintainer you have to make sure that "debian/watch" works and that tarball workflow works first. If that works then importing upstream into packaging git repo is redundant. > I agree in principle but my solution does not involve giving up on git > packaging tools entirely :) Whatever works for you without adding complexity to your co-maintainers is the best. I like "gbp dch --full" command -- perhaps the most (if not the only) useful tool from git-buildpackage. > 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. Nonsense. It does not matter if instead of latest release you have to download "well packed" history of all upstream releases ever packaged in Debian. You should not have to do that when it is not necessary. If you need archaeology then clone upstream repository, or download prior releases from Debian. Bandwidth is not the only, or most important concern. When you work on many packages, repositories grow not only in space but also in numbers of files and everything is getting slower. You'd notice when your repository grow to have around 100,000 files so you do slow and CPU-intensive "git gc --aggressive" and doing that on many repositories is tedious. Storing all upstream releases in "upstream" branch of packaging repository is unjustifiable, even if that became common/normalised packaging practice. On small packages it is a little pain, but on large and complex packages it is a big pain, so big that certain packages can not be maintained in such manner. > 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. Only something very uncommon needs to be documented within package itself. For everything else there is plenty of information and general-purpose approach to building packages is best to document elsewhere, outside of package (e.g. in wiki). Remember that everything committed is technical liability (debt) that takes time to maintain. > Many prominent packages use it after all. And many don't. So? Majority decision is rarely a most sensible one. > IMO if alternate workflows want to have any success they need > to be visible. To whom? Isn't it a matter of attention? And sometimes it is a matter of consensus or established practice within a team. Complicated git workflows violate principle of least surprise. -- All the best, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- Politics: the art of using euphemisms, lies, emotionalism and fear-mongering to dupe average people into accepting — or even demanding — their own enslavement. -- Larken Rose
Attachment:
signature.asc
Description: This is a digitally signed message part.