Package: debhelper Version: 10.7.2 File: /usr/bin/dh_install User: helm...@debian.org Usertags: rebootstrap Control: affects -1 + src:gnumach
I noticed that cross building a gnumach stage1 for hurd-i386 started to fail. Sucessful log: https://jenkins.debian.net/job/rebootstrap_hurd-i386_gcc7/7/console Failing log: https://jenkins.debian.net/job/rebootstrap_hurd-i386_gcc7/9/console Interesting bit: Both use gnumach 2:1.8+git20170609-1. Notable difference: debhelper 10.2.5 vs 10.7.2. The failing command is: | dh_install -pgnumach-image-1.8-486 --sourcedir=/tmp/buildd/gnumach_1/gnumach-1.8+git20170609/debian/tmp boot In this command line, gnumach-image-1.8-486 is a package disabled by the profile stage1 and stage1 is active. The file "boot" isn't built an unavailable. (Applies to both logs.) It seems that gnumach assumes that "dh_install -pfoo ..." is a noop (regardless of the files referenced) if foo is disabled by a profile. That assumption was broken somewhere from debhelper 10.2.5 to 10.7.2. Whether that assumption is a good one is beyond my judgement. Imo, the documentation does neither contradict nor support it. If that assumption is reasonable, it should be documented and restored in debhelper. Otherwise the bug is found in gnumach and should be fixed there. Please choose the victim reasonably. Helmut
