Hi! On Sat, 2022-12-17 at 12:07:22 +0100, Niels Thykier wrote: > On Fri, 16 Dec 2022 13:13:34 -0500 Garrett Kajmowicz wrote: > > Package: debhelper > > Version: 13.6ubuntu1 > > Severity: wishlist
> 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. > > > I'm working on a use-case which can be generalized as wanting to be able > > to perform a build with debhelper in a read-only source directory. Not > > simply that the files themselves are read-only, but that the full > > directory > > tree is read-only. [...] > > Ok. As you have discovered, having a read-only source directory is not a > use-case that the Debian build stack supports at the moment. The build > process is largely working with the assumption that the source package is > copied to a writeable directory and then built there (i.e., you have a > writeable base directory and then unpack the source package into a subfolder > of that directory). Right, and while I'm happy to entertain the possibility to support something like this, it seems a bit like one of those gargantuan projects we might end up with. So, I guess I'd also like to understand the motivations, and perhaps whether other alternatives are not fulfilling? :) I've not checked very deep on what might be blocking this, or whether there might be other difficulties, so do not take the following as extensive. > 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. This would currently be blocked by at least something like #657401, I think > 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). I think this is partially blocked on something like <https://lists.debian.org/debian-devel/2020/03/msg00085.html>, and because several of the currently written files are part of the expected interface. :/ > 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". The overall problem, IMO, is the original packaging design we've got in front of us, with package building being inside-out, where the build is mainly driven by the package itself, instead of an external driver. We have discussed this with Niels in the past, and we have some WIP work (which I should merge the dpkg side of and email out, something I had actually in mind talking with Niels already the past weeks!). But I'm not seeing this (at least right now) being used by Debian for example. :/ > 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". > > => 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). The main problem I see there, besides the current pathnames as interfaces, is that I don't think this can be universally supported by any package, and as such something like dpkg-buildpackage would need to way to know whether the package supports this mode, for every and each package (say a field such as the R³ marking), and if it that does not get tested per package, then it will tend to break. :/ So I think I'm also currently in the "does it outweigh the cost?" pondering phase too. > > 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). Also I'd expect many source packaging (say overrides in debian/rules or even debian/rules not using dh or debhelper), ancillary packaging tools (say dh extensions) might expect pathnames to be in specific locations. > > 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. > If it is a bug, then it is a separate one for dpkg. I will let Guillem > comment on that. Thanks, I've not yet checked what might be going on, but I'll do and try to fix it! In any case, sorry, I think the outlook might not be very bright, but as I've said at the beginning, I'm happy to still entertain this. Thanks, Guillem
