Garrett Kajmowicz:
[...]
The C1) case is something that could be useful for Debian itself. There are
some tools that want to choose the location of the produced artefacts. It has
been a low priority wish for me to have this solved "eventually".
I'm using multiple work-arounds for the project I am working on. The C1 work
by itself would still let me tidy some things up and so would be appreciated.
Good to know. I also suspect C1 is easier for us to implement in a short
time frame.
For the C2) case, it is not that I cannot see possibilities in it. I am more
whether it outweighs the cost of doing it.
=> If we are going for C2, I would expect that you provide CI test
cases to ensure the feature does not regress (at least for debhelper
for the gitlab CI pipeline). Otherwise, it is going to be a game of
"whack-a-mole".
I have little experience with either gitlab or perl. Still, if you provide me a
few pointers I can certainly throw a few hours into developing some CI
tests for this.
It does not have to be perl. A shell script that can setup a test
package that is built with dh is sufficient inside gitlab CI is fine.
In case you have experience with GitHub CI, then it is a different
syntax but otherwise the same concept. As an example, the current
debhelper CI snippet for testing changes is:
"""
tests-unstable:
stage: test
image: debian:unstable
script:
- apt-get update
- apt-get build-dep -y .
- dpkg-buildpackage -us -uc -tc
"""
In theory, you would insert snippets in the "script:" part to setup the
source package that debhelper is supposed to build (with the features
you want to test), create the output directory, mark the source
read-only somehow and then cd into followed by dpkg-buildpackage.
This would suffice as a single black box test. Probably we would need a
battery of them, so you would wrap it in a script to try different test
cases but that can be done in shell or whatever you are comfortable.
=> For C2, You may also have to do patches and tests for dh-autoreconf
and dh-strip-nondeterminism as they are part of the default dh
pipeline (and not maintained by me nor Guillem).
I can certainly take a stab at it. The required changes for both of these
appear to be straight-forward: use the new parameter passed from
above (however architected) as-needed for the paths being processed.
Side note: patching ltmain.sh in-place strikes me as ... worrisome.
Actually, come to think of it, The dh-autoreconf tool's purpose is to
*replace* (regenerate) the "configure" script from latest sources. So
this pretty much implies that the source directory have to be writeable
if dh-autoreconf is to do anything.
So as long as it properly no-ops for non-autoconf packages, I think we
should be fine here.
One possible solution to this is to have:
1) dpkg-buildpackage gets two new parameters. One for the artifact
output directory and one for the writeable scratch directory.
2) dpkg-buildpackage would export these directories as environment
variables for the build process (debian/rules + debhelper).
3) debhelper (and anything in debian/rules) would pick up these
environment variables to write to the correct places.
4) dpkg-buildpackage would pass relevant options to dpkg-genbuildinfo
and dpkg-genchanges (etc.), so they are aware as well.
Should debuild itself be modified to support passing in these build
Parameters as well?
In theory, yes. But really, all "*-buildpackage"-like wrapper tools
should do that.
Though for starters, lets get support in dpkg-buildpackage first and
then worry about patching the other tools.
@Guillem: What is your views on this?
Many of the required capabilities are already supported. For example,
the --builddirectory flag allows the building step to be placed in a
different directory.
While there are many options that package can use to tweak locations, they
are not aimed at the thing you are doing. Notably the dh_* -P option is really
painful to use at scale (if you have multiple binary packages in the same
source package).
Huh. I assumed that these would be automatically use
builddirectory/debian/<package>
directory unless manually overridden.
No, the "builddirectory" is only for the "upstream" build system.
[...]
Okay. I'll await his response as well.
Hope that was useful.
It's fantastic.
Thank you!
- Garrett
Glad you are excited, though keep in mind that there are no guarantees
at this point. If (for whatever reason), dpkg cannot/will not support
this change, then there is not a lot I can do in debhelper to solve
this. (And also, we are volunteers, so we generally do not offer
guarantees either even if we can/want to support a feature)
Thanks,
~Niels
