¡Hola Edmund! El 2026-09-29 a las 20:31 +0200, Edmund Lodewijks escribió:
It's a second binary package from the same source package, it doesn't require a second repository. To add the package you add a new paragraph in debian/control. Handling a package that builds more than one binary is slightly different than to handle a single one, as the target directory is debian/tmp instead of debian/$pkg, and then you need to install the files to the corresponding debian/$pkg from debian/tmp.
Thank you, and Simon McV, for the explanations and links to examples! I remember now that I have seen this before in debian/ files.
I must say that taking a second look it makes little sense to split the package. :)
Would you mind sharing the reason for this? Is it that you think the python module part as a stand-alone makes no sense? Or currently has no reverse dependencies? Just trying to understand.
Well, the entry point is a trivial script only starting the correct module, so a binary package that only contains that seems overkill. The script seems to be the main part, if at some point the python module starts to be used by others then you might want to add a -doc package, and probably add a Provides: python3-desec so users of the module might find this package more easily. You might even consider renaming the binary package python3-desec if the modules becomes the primary use of this package, but even then you will want to keep the script desec in the same package.
Am I correct in assuming that the current package name (desec-dns) is the correct one, and no python-desec-dns is needed at the moment?
Correct.
CI is green (https://salsa.debian.org/python-team/packages/desec-dns/-/pipelines/1179747).
Besides the CI Tutorial and the examples, I found https://manpages.debian.org/unstable/dh-python/pybuild-autopkgtest.1.en.html very useful.
Ok, I'll upload it as is (uploaded).
The current situation (just adding "Testsuite: autopkgtest-pkg-pybuild") uses all the Build-Deps from the build, which is technically more than needed. But, it means that no one has to manually check that the correct test deps are loaded in d/tests/control, should they ever change. It seemed like a fair trade-off, but perhaps you would suggest that I should be less comfort-seeking and lazy?
I could, but I'm a bit lazy, so I'll leave this for you to decide. Further improvements: Probably most of the package that are listed in the build depends are actually only needed for the tests to run. In Debian there are build profiles, that might be used in certain situations, for example, to allow bootstrapping, one of them is "nocheck", which is aimed for a faster build with less dependencies by not running the tests. All this to say add the a "<!nocheck>" to the dependencies that are only needed for the tests. If you use sbuild you can test this using the option --builder-profile=nocheck. Happy hacking, --"Good judgement comes from experience, and experience comes from bad judgement."
-- Fred Brooks Saludos /\/\ /\ >< `/
signature.asc
Description: PGP signature
