[debhelper-devel] Bug#872745: Bug#872745: dh_install: now bails for missing files in disabled packages

[Niels Thykier]

Control: tags -1 wishlist

Helmut Grohne:
> Package: debhelper
> Version: 10.7.2
> File: /usr/bin/dh_install
> User: helmutg at 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:
> 
> [...] 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.
> 

Turns out that this assumption never worked in general, but only for
dh_install and only by accident.  Recently it would have worked with
more tools that started to integrate with dh_missing (e.g.
dh_installman) until it all "broke" in
60e1f08257c7361bf4730769f37de34141355148.


This is presumably why the package does *not* rely on this for dh_compress:

"""
ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
	dh_compress -p$(pkg) boot/gnumach-$(VERSION)-$(MACHINE)
	dh_compress -p$(pkg_xen) boot/gnumach-$(VERSION)-xen-$(MACHINE)
ifeq ($(DEB_HOST_ARCH_OS),hurd)
	dh_compress -p$(pkg_udeb) boot/gnumach
	dh_compress -p$(pkg_xen_udeb) boot/gnumach
endif
	dh_compress -p$(pkg_dbg) boot/gnumach-$(VERSION)-$(MACHINE)-dbg
	dh_compress -p$(pkg_xen_dbg) boot/gnumach-[...]
endif
"""

> Whether that assumption is a good one is beyond my judgement. Imo, the
> documentation does neither contradict nor support it.  [...]
> 
> Helmut
> 
> [...]

I am all for making packaging easier to get right.  I am considering
whether this is the right approach for it though.  At first glance, the
dh_install part is probably better solved with the buildlabel feature
(currently a prototype in experimental).

Not entirely sure about the dh_compress yet.  At least, the buildlabel
feature is not applicable there.

Thanks,
~Niels