On 2026/09/29 13:20, Maximiliano Curia wrote:
This is a good start: https://ci.debian.net/doc/file.TUTORIAL.html
Thank you, I wasn't even aware of this site!
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. 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?
Happy hacking,
Thanks!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.
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?
Kind regards,
Edmund
--
Edmund Lodewijks <[email protected]>
TZ: UTC+2 / GMT+2
OpenPGP_signature.asc
Description: OpenPGP digital signature
