On Mon, Nov 18, 2024 at 05:40:55PM +0200, Kari Pahula wrote: > With all the recent talk about increasing the use of git for > packaging, I'd like to address one thing: git-buildpackage is very > complex to use. As an alternative, I'd like to propose a simpler > setup:
We want fewer allowed setups, not more. Though it's clear to me at this point that if this become more than a dream, we will need to allow more than one. > - Only store debian/ in the repository and use origtargz for the rest. > > - One branch per distribution you target. > > - Only tag debian revisions. --git-overlay probably supports this, but it's not really documented so I don't really know. > That's it, less is more. The master branch would be just a single > debian directory. What it specifically wouldn't have is an upstream > branch and no extracted upstream sources in any permanent branch. Many people want to have version-tracked upstream sources so this can't be the only allowed workflow. > gbp dch would still be useful with this workflow. gbp pq could be > made to work with this if you extracted orig.tar and committed it to a > temporary local working branch and used it against it. "How do I create and update patches" is actually a big part of a good workflow, and this way doesn't sound easy. Though of course there is no way to have 3.0 (quilt), git and easy patch workflows at the same time. > I guess interfacing with upstream's git with gbp has its uses but it > just seems to me that the capability comes with a hefty cost. If you > can maintain a package with having orig.tar files be your interface to > upstream's releases then it simplifies things on our side a whole lot. It's not necessarily interfacing with upstream's git, just version-tracking tarballs is already very useful. Maybe more useful than the upstream git in certain use cases. > I've been a DD longer than git-buildpackage has been around and I've > been looking at using it at various times but pretty much every time > my reaction's been "must I?" I know a lot of people do use gbp daily > for work with good effect but somehow I suspect even they had quite a > steep learning curve to get into it. I wouldn't fancy the idea of > trying to explain how to use it to someone on d-mentors. I have many interconnected thoughts about this: 1. git-buildpackage is complicated because it supports many different workflows, some of which don't have anything in common. This simply represents a bigger problem in Debian and is not specific to git-buildpackage. 2. git-buildpackage is bad. This is unavoidable, because any tool that tries to wrap the inherently incompatible Debian packages workflow into a VCS will be bad in some way. So we don't and, unavoidably, can't have a better tool and must work with what we have. 3. git-buildpackage has a steep learning curve, but I don't expect it to be that steep for people who are already proficient both with Debian packaging and with git. Which new users aren't, at least because of the former, but it's far from the only thing with a steel learning curve and not enough docs they will hit their heads against. 4. git itself has a steep learning curve, bad UI, bad docs etc. etc., but we clearly don't have a better VCS to store packages in, and we really need to do that. And, at least, git knowledge is both useful outside Debian and possible to already have before becoming a Debian package, unlike almost everything else you need to know in Debian packaging. 5. *Debian packaging itself* is notoriously hard to learn, and as long as it stays as hard as it is now not a lot of things on top of it could make the overall experience harder and some of them may make it *easier* for many people. 6. Whatever workflow one needs to learn, even if it's just a single one, will be hard for a newbie in a large part because of the disconnect between the VCS concept and the "source package as a first class citizen" concept, even before we talk about patches, uscan and upstreams without tarballs. Long story short, I don't envy our newbie contributors and I don't think it will be easier for them in my lifetime. > I must say that I haven't been that impressed with the DEP-18 > discussion I've seen. It seems like the message has pretty > consistently been "if you don't use git you're the problem" and I'm > sick of it and I can tell you it only makes me want to ignore you. I'm afraid I don't see a peaceful way forward for the project. Most likely we will continue stagnating and losing people but in a less probably scenario with big changes many people will resign. > If you ask me it's git-buildpackage's irreducible difficulty of use > that's the largest road block to increase the use of git for packaging. :-/ -- WBR, wRAR
signature.asc
Description: PGP signature
