Hello Paul,
Am 29.03.24 um 13:49 schrieb Paul Boddie:
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.
the question in general was not about the right and correct way in the
DPT, it was about starting from scratch. At least I don't know of a
right way from scratch that is written down as policy, would also make
no real sense to me.
Starting Debian packaging isn't easy, but it's going to be more
complicated if you think there is only one way that's correct. In the
end DAK needs some files, how you create them is on your own.
The DPT policy doesn't say you need to do packaging a very specif way,
it stated that git-buildpackage is the tool for organizing the VCS data.
The DPT policy gives you the freedom to do your packaging preparation
how ever you like, but it is expected you finally upload the data of
your work into a git tree with a specific layout so others can take your
work and reproduce a package by using gbp.
gbp is very flexible, so if you like to use sbuild in favor of pbuilder
e.g. than you can simply do so.
BTW: I posted my way on how I created a new Python package for Debian in
the German Debian forum extensively and in length last year while DC
[1]. Because I also know were starters typically struggle with and I was
in the need to introduce a new Python package as a dependency for
another package.
I'm unsure if Christian did follow my steps by trying to reproduce the
package I was working on. I'm thinking he didn't, if he did then I'm
wondering where he is having problems to prepare his package. Until now
there is no "I did this and this, ..., I failed."
The feedback on my mini HowTo was quite low. So I wont do such things again.
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
gbp makes all these steps easier I think. Even if you want to do it
completely manually. Basically I do this
mkdir new-package && cd new-package
git init
# create a file debian/gbp.conf if you want to have it more convenient
gbp import-orig [--verbose] --sign-tags --pristine-tar /path/to/tarball-version.tar.{gz,...,xz}
# add required files into debian/
gbp dch -aR
gbp buildpackage --git-ignore-new [--git-builder=what_ever_you_like]
# run lintian, squash issues, prepare autopkgtest, commit changes atomically
# create a patch queue if needed
gbp pq import [--ignore-new]
# work on patches, commit them
gbp qp export
git add debian/patches && git commit
# hack further, finalize the package, create the final changelog entry
if needed
git commit debian/changlog
gbp buildpackage ...
# upload, wait for the DAK email
gbp tag --sig-tags
git remote add salsa ....
gbp push [salsa]
But we will find ten more possible ways to create a new package from
scratch. :)
...
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.
A good tool is always helpful, and a good first time user experience is
also important. But I've seen a lot of people and contributors that were completely lost once a errors message was coming up and they did not
know what to do and were to look. A good developer or engineer is always
able to help themselves. Means he need to know how things work or at
least were to look next to solve problems.
[1]
https://debianforum.de/forum/viewtopic.php?t=187764
--
Regards
Carsten
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)