Santiago Vila: > On Thu, Jan 11, 2018 at 06:39:00AM +0000, Niels Thykier wrote: > >> This seems like a legitimate bug. >> >> What happens is that debhelper notices that base-files explicitly >> defines an install target and recurses into that (dh, unlike policy, >> also defines an "install(-arch|-indep)" sequences as a part of the >> "binary" target). However, being a "sequence" target, dh does not >> define "DESTDIR" for that call (it assumes the install target will >> eventually trigger the upstream build system plus run dh_install*). >> >> This case would only trigger if you do a "debian/rules binary". So this >> would probably build fine as a source-only or source + all upload (as dh >> concludes it should only care about the "install-indep" sequence in the >> arch:all build and "install-arch" on the rest of the builds). >> >> The simple solution is probably to just rename the "install" target to >> something other than "install", "install-arch" and "install-indep". > > I'm confused. Do you mean that the install target is "taken" > and packages may not freely use it in debian/rules? >
Afraid so; it occurred before my involvement in debhelper, but I think it used to be more common for packages to also have an "install" target and debhelper basically mirrored that (with -arch + -indep variants). > Also: Is this the kind of FTBFS bug that should be fixed in stable? > (I think maybe not because it does not happen in autobuilders, > as they do dpkg-buildpackage). > > Thanks. > I think the SRMs will be happy with a patch for this in stable as well. Thanks, ~Niels