On Friday, 29 March 2024 09:52:14 CET Carsten Schoenert wrote: > > Starting with Debian packaging isn't a easy thing and there is *not* the > one way to do it right. And there are for sure hundreds of HowTos out > there. You will need to try a few of them and chose in the end the > workflow that fit's best for you.
The problem with this advice is that for the Debian Python Team, there probably aren't many ways to "do it right". Instead, as I understand it, there will be very few ways that people tolerate, as recent discussion on this list has indicated. > git-buildpackage is one of the high level tools that can and should > packaging tasks easier, to use it effective you will need to know what > it is doing under the hood, means you need to be familiar with the low > level tools that getting called by gbp. I packaged stuff for Debian about ten years ago or so and recently repackaged one tool, whose package is now parked in a state where it could conceivably be incorporated into Debian but is evidently not of interest to anyone here (or I need to promote it more, perhaps). I have also been packaging Moin 2.0 which is coincidentally relevant to these documentation discussion threads. After following the advice on the Debian Wiki about suitable approaches for packaging Python libraries and applications, I ended up reading all about gbp and trying out the different suggestions in its documentation. Although quite helpful, this documentation does not give concrete advice about what would-be packagers should do, so it really does fall on context-specific advice to fill in those gaps. In the end, I did my usual thing and distilled the documentation's prose down to a concise workflow to remind me of what I might need to do if I were to start packaging something else. In fact, I wrote the following for the Moin 2.0 packages and then made use of it for the other package: git branch -c master upstream git checkout -b debian/master <introduce debian directory here> git add debian git commit <introduce upstream tag here, if you want to avoid hassle with Salsa> git push origin <upstream tag> gbp buildpackage --git-debian-branch=debian/master \ --git-upstream-tag='upstream/%(version)s' --git-builder=sbuild This saves me from having to re-read the gbp documentation or find the appropriate mention on the Debian Wiki of whatever the accepted approach might be. I also wrote summaries to maintaining patches since it seemed that gbp could be quite obstructive if not operated in precisely the right fashion, not entirely obvious from its documentation. Obviously, this leaves a lot of stuff out, but it is a reminder and not a complete guide. Indeed, the issue of what the Debian directory might contain is almost an orthogonal topic to the mechanics of gbp. And then there are the social or collaborative aspects of the exercise as well, like setting up a Salsa account and project, filing an ITP, and so on. Yes, such matters are covered in the more general documentation, at least if it was updated and no longer refers to Alioth or whatever. But in this context the advice will be quite specific and not vague suggestions that present more choices to be made rather than eliminating them. In any case, I commend this effort to improve the documentation. In some ways, it really is quite a brave endeavour. I would have made edits to various pages myself, but I don't want to tread on any toes, and I don't really have much time to spend on this matter alongside numerous other commitments at the moment. Paul P.S. The argument made about needing to understand what happens "under the hood" is something of an indictment of the way technology is developed these days. A tool that is meant to simplify something should present its own coherent level of abstraction; deferring to lower-level mechanisms is something that the Git developers and community like to do, which is why the usability of Git is the subject of occasional jokes and somewhat more infrequent attempts to wrap it in more usable interfaces.
