[debhelper-devel] Bug#879054: gcc-8 DEB_STAGE=rtlibs FTBFS: dh_installdirs: All requested packages have been excluded (e.g. via a Build-Profile).

[Helmut Grohne]

Source: gcc-8,gcc-7
Tags: patch
User: helmutg at debian.org
Usertags: rebootstrap

Hi Matthias,

since debhelper 10.9.1, more specifically
https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?id=93d8fdfc5dfc994af53fc6fed7f36f271b3abee5
the DEB_STAGE=rtlibs build of gcc fails. Such builds use an environment
where DEB_BUILD_ARCH=DEB_HOST_ARCH=DEB_TARGET_ARCH, but internally set a
different TARGET and try to produce binaries for that TARGET. When
various dh_commands are instructed to operate on such packages, they now
figure that they are not enabled for DEB_HOST_ARCH and thus skip them:

| dh_installdirs -plibgcc1 usr/share/doc/libgcc1 /lib/x86_64-linux-gnux32
| dh_installdirs: All requested packages have been excluded (e.g. via a Build-Profile).

Turning some helpers into noops quickly makes the build fail.

I think that the cure is to call those helpers in an environment where
DEB_HOST_ARCH is set to the TARGET. The attached patch thus introduces a
$(for_target) prefix for affected commands and identifies which commands
need the prefix. After applying it DEB_STAGE=rtlibs does build.

Of course the other question is: What does the patch break? Whenever
DEB_HOST_ARCH is equal to the TARGET, the prefix does not actually
change anything, so native builds and cross builds are completely
unaffected. We only need to look at cross compiler builds (such as
DEB_STAGE=rtlibs, but also other stages). With the exception of
DEB_STAGE=rtlibs, the affected packages become Architecture: all (in the
typical dpkg-cross suffixed notation). Thus the change in DEB_HOST_ARCH
is mostly irrelevant there as well (and I did perform the full 4-stage
cross compiler bootstrap with the patch). For these reasons, I believe
that the attached patch has a low risk of introducing regressions.

I do note that Niels Thykier has been working on an alternative solution
involving support from debhelper:
https://anonscm.debian.org/git/debhelper/debhelper.git/log/?h=dh-cross-target
That branch enables tagging binary packages in debian/control to use
DEB_TARGET_ARCH whenever debhelper normally thinks DEB_HOST_ARCH. Using
this debhelper branch would allow tagging binary packages rather than
dh_commands, which generally means less tagging and thus a smaller risk
of mistakes. The approach would also allow building updates packages on
jessie and stretch, because their debhelper lacks ignores the new header
and lacks the breaking commit above. Please tell if you prefer that
approach.

Helmut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-8-debhelper.patch
Type: text/x-diff
Size: 6437 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debhelper-devel/attachments/20171018/d62c7100/attachment.patch>