On Fri, 16 Dec 2022 13:13:34 -0500 Garrett Kajmowicz
<garrett.kajmow...@sophos.com> wrote:
Package: debhelper
Version: 13.6ubuntu1
Severity: wishlist
Dear Maintainer,
Hi Garret
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).
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".
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).
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.
@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).
[...]
The debhelper scripts are causing a few issues. The immediate issue which has
led me to file this ticket is that debhelper really wants to write log files
into the source directory. This results in an error such as:
dh_autoreconf_clean: error: failed to write to debian/<package>.debhelper.log:
Read-only file system
I tried to work around this by hacking up the debhelper scripts in the Docker
image by doing:
RUN sed -i -e
's!"debian/${ext}debhelper.log"!"/working/debian/${ext}debhelper.log"!g'
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm
RUN sed -i -e 's!debian/\*.debhelper.log!/working/debian/\*.debhelper.log!g'
/usr/share/perl5/Debian/Debhelper/SequencerUtil.pm
RUN sed -i -e 's!debian/\*.debhelper.log!/working/debian/\*.debhelper.log!g'
/usr/bin/dh_clean
This failed because the script was unable to find the log file to delete, with
error message:
dh_autoreconf_clean: error: failed to write to
/working/debian/<package>.debhelper.log: No such file or directory
The code assumes the directory exist. I assume a mkdir -p
/working/debian would solve that immediate error. However, you would
hit the next wall one step further ahead, so do not expect much progress
from that "mkdir -p".
Also, if you know you have "clean" source directory, you can skip the
clean process with "dpkg-buildpackage -nc".
[...]
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.
Hope that was useful.
Thanks,
~Niels
