Santiago Vila:
> On Thu, Jan 11, 2018 at 08:10:00PM +0000, Niels Thykier wrote:
>
>>> 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).
>
> I must be missing something, then, because today I've checked that
> "dpkg-buildpackage":
>
> - Works ok in stretch.
> - Does only fail in buster/sid (I actually tried it in sid).
>
> ("dpkg-buildpackage -B" works ok in both stretch and buster/sid).
>
debhelper before 11.1 had a very suboptimal handling of sequence targets
in debian/rules (reported in #880840). In debhelper/11.1, this was
fixed by properly treating d/rules targets as opaque and assuming that
the target will properly delegate tasks on as necessary.
This bug has been present more or less since compat 9 was introduced,
but we have not noticed until now. I suspect it is related to how
dpkg-buildpackage calls d/rules, which somehow hides the issue in
base-files (but shows a bug in the behaviour of debhelper/10.2.5).
In a clean base-files source checkout, you can see that dh thinks it
should run "debian/rules install":
$ dh binary --no-act | grep 'debian/rules install'
debian/rules install
$
(You can see the suboptimal handling of this target by looking at the
full sequence. dh actually wants to run "debian/rules install" as the
very first thing before calling any of the build commands and will then
follow it by calling the build + install commands *again*)
But if you emulate the way dpkg-buildpackage calls the rules file, then
the "debian/rules install" call disappears in debhelper/10.2.5:
$ dpkg-buildpackage -us -uc -T build
[...]
$ dh binary --no-act | grep 'debian/rules install'
$
The absence of the "debian/rules install" is a technically a violation
of the API that debhelper promises for compat 9 packages, which says:
"""
> - dh is aware of the usual dependencies between targets in
> debian/rules. So, "dh binary" will run any build, build-arch, build-indep,
> install,
> etc targets that exist in the rules file. There's no need
> to define an explicit binary target with explicit dependencies on the other
> targets"""
(Turns out that Joey happened to list "install" explicitly before the
"etc.". I had not noticed that until now.)
For the record, debhelper recognises the following sequence targets:
* build, build-arch and build-indep
* install, install-arch and install-indep
* binary, binary-arch and binary-indep
* clean
They were present for as long as I mentioned debhelper and I assume they
were present since debhelper/9 (but I haven't bothered digging in the
git log to confirm that).
> Fixing this is base-files would be trivial, of course, but before I do
> that I'd like to confirm that it's a bug in base-files.
>
> Considering that this used to work in stretch, are you sure that
> debhelper is following the "specs"?
>
> Thanks.
>
I believe debhelper finally follows the spec it set for itself and I
would appreciate if we fixed it in base-files. Apologies for the extra
work on your end.
Thanks,
~Niels
