> I have CC'ed Guillem Jover because *if* this is a change to be supported, > then it would need dpkg and debhelper to support it.
Great! I look forward to hearing his response as well. > For this to be possible, it would require two "independent" features in the > Debian build stack: > > C1) Provide a writeable directory for the output artefacts (the > produced .debs, the .changes file etc.) > - This would enable to the parent directory be read-only. > > C2) Provide a writeable directory for the build process itself. > - This would enable the source directory itself to be read-only. > > => There will be packages that *cannot* support C2 as they only > support "in-source" built (which is probably why we have the > current setup in the first place). > > > 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. > 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. > => 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. > 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? > @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. > > One other possibly-related item of note (I can file a separate bug if > > you like) and which may have an existing solution: > > Passing in --buildinfo-option=-u/out still results in a -O option which > > refers to the wrong directory. That is, I get the following: > > dpkg-genbuildinfo -u/out --build=binary -O../<package>_2.0.6- > 1_amd64.buildinfo > > dpkg-genbuildinfo: error: cannot write > > ../<package>_2.0.6-1_amd64.buildinfo.new: Permission denied > > > > This resulted from an experiment where I was copying the source code > > to a temporary directory with read/write permissions, but where the > > parent directory was not writable. > > > > Thank you for your time, > > > > - Garrett > > > > > > [...] > If it is a bug, then it is a separate one for dpkg. I will let Guillem > comment on > that. Okay. I'll await his response as well. > Hope that was useful. It's fantastic. Thank you! - Garrett
