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

Reply via email to