Bug#645873: incorrect target discovery w.r.t. arch dep/indep
On Wed, Oct 19, 2011 at 05:15:00PM -0700, Joey Hess wrote: Marcin Owsiany wrote: I also thought that in (1) the override_* targets do not play any role. It's only in (2) that it matters what override_* targets are defined, because that's how dh decides which of them to call instead of the dh_* commands. So the problem is probably that when make is run to dump a list of makefile targets, DH_INTERNAL_OPTIONS is not populated with the packages that are being built. However, since those packages can potentially vary for each command in the sequence, dh would need to run make more than it does now. I think what you're doing is unnecessary and I am not motivated at all to complicate dh with the necessary special caching that would be needed to support it without badly slowing down everything else. Especially since -arch and -indep override targets now exist (in 8.9.7). And I think that's fine, though it might make sense to mention in the docs that conditionally disappearing whole targets are not supported, to save others some potential pain. -- Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645873: incorrect target discovery w.r.t. arch dep/indep
Package: debhelper
Version: 8.9.0
Priority: important
Justification: can cause builds of packages that violate policy
Consider a following snippet:
| ifneq (,$(findstring libgadu-doc, $(shell dh_listpackages)))
| override_dh_installdocs:
| dh_installdocs
| # nicer name for api docs directory
| mv debian/libgadu-doc/usr/share/doc/libgadu-doc/html \
| debian/libgadu-doc/usr/share/doc/libgadu-doc/api
| endif
My theory is that when dh detects what override_* targets are defined,
it does not set up environment correctly, so that dh_listpackages always
lists all packages, regardless of what build is in progress, and
consequently the override_dh_installdocs target is discovered every
time. However then when it actually invokes the override_dh_installdocs
target, the environment is set up properly, which means that in
build-arch case the target definition is omitted by make, and just dh
gets called (through the pattern rule) with the override_dh_installdocs
argument, which it just ignores and exits 0.
This way, dh_installdocs is never run on build-arch builds, resulting in
my case in http://bugs.debian.org/645750 - no copyright file in the
autobuilt arch-dependent packages.
I've noticed that the example in the 8.9.0 manpage has the ifneq/endif
surround just part of the rule, rather than all of it, which I think can
mitigate this problem. However there is no mention that this problem can
occur, so it might be good to add a few words about it if you don't
intend to fix this bug for some reason.
Initially I thought that this is not easily fixable, but then I've
realized that at least make 3.81-7 does run the $(shell) commands in the
conditional statements, as demonstrated by the following example:
$ cat ~/tmp/t.mk
ifneq (,$(findstring yes,$(shell echo $${yesno})))
branch-number-one:
else
branch-number-two:
endif
$ yesno=yes make -Rrnspf ~/tmp/t.mk|grep ^branch-number
branch-number-one:
$ yesno=no make -Rrnspf ~/tmp/t.mk|grep ^branch-number
branch-number-two:
$
--
Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645873: incorrect target discovery w.r.t. arch dep/indep
Marcin Owsiany wrote: Consider a following snippet: | ifneq (,$(findstring libgadu-doc, $(shell dh_listpackages))) | override_dh_installdocs: | dh_installdocs | # nicer name for api docs directory | mv debian/libgadu-doc/usr/share/doc/libgadu-doc/html \ |debian/libgadu-doc/usr/share/doc/libgadu-doc/api | endif How can this possibly work? the ifneq is parsed when make parses the makefile, well before dh does anything. So of course it lists all packages. I've noticed that the example in the 8.9.0 manpage has the ifneq/endif There is no such example in debhelper 8.9.0, except possibly a fuzzy one in the Spanish man page, and that one puts the ifneq inside the target, which I think probably does work. The new way to accomplish this is to use override_dh_installdocs-indep -- see shy jo signature.asc Description: Digital signature
Bug#645873: incorrect target discovery w.r.t. arch dep/indep
On Wed, Oct 19, 2011 at 10:26:50AM -0700, Joey Hess wrote: Marcin Owsiany wrote: Consider a following snippet: | ifneq (,$(findstring libgadu-doc, $(shell dh_listpackages))) | override_dh_installdocs: | dh_installdocs | # nicer name for api docs directory | mv debian/libgadu-doc/usr/share/doc/libgadu-doc/html \ | debian/libgadu-doc/usr/share/doc/libgadu-doc/api | endif How can this possibly work? the ifneq is parsed when make parses the makefile, well before dh does anything. So of course it lists all packages. Correct me if I'm wrong, but I was under the impression that make is ran twice on debian/rules: dpkg-buildpackage | \_ make -f debian/rules target (1) | \_ dh target | \_ make -Rrnspf debian/rules debhelper-fail-me (2) I also thought that in (1) the override_* targets do not play any role. It's only in (2) that it matters what override_* targets are defined, because that's how dh decides which of them to call instead of the dh_* commands. And I assumed that dh sets up the environment in such way that dh_listpackage knows what target is being built. Isn't that how this works? I've noticed that the example in the 8.9.0 manpage has the ifneq/endif There is no such example in debhelper 8.9.0, I mean this piece: | Sometimes, you may need to make an override target only run commands | when a particular package is being built. This can be accomplished | using dh_listpackages(1) to test what is being built. For example: | | #!/usr/bin/make -f | %: | dh $@ | | override_dh_fixperms: | dh_fixperms | ifneq (,$(filter foo, $(shell dh_listpackages))) | chmod 4755 debian/foo/usr/bin/foo | endif Perhaps that was added by ubuntu? mowsiany@beczulka:~$ LANG=C dpkg -l debhelper Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii debhelper 8.9.0ubuntu1 helper programs for debian/rules except possibly a fuzzy one in the Spanish man page, and that one puts the ifneq inside the target, which I think probably does work. Right, that's what I meant by part of the rule. The new way to accomplish this is to use override_dh_installdocs-indep Oh, nice. Which version is this available from? -- Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645873: incorrect target discovery w.r.t. arch dep/indep
Marcin Owsiany wrote: I also thought that in (1) the override_* targets do not play any role. It's only in (2) that it matters what override_* targets are defined, because that's how dh decides which of them to call instead of the dh_* commands. So the problem is probably that when make is run to dump a list of makefile targets, DH_INTERNAL_OPTIONS is not populated with the packages that are being built. However, since those packages can potentially vary for each command in the sequence, dh would need to run make more than it does now. I think what you're doing is unnecessary and I am not motivated at all to complicate dh with the necessary special caching that would be needed to support it without badly slowing down everything else. Especially since -arch and -indep override targets now exist (in 8.9.7). | override_dh_fixperms: | dh_fixperms | ifneq (,$(filter foo, $(shell dh_listpackages))) | chmod 4755 debian/foo/usr/bin/foo | endif Here the target exists no matter what, which will always work ok. Making the target conditionally not exist is the problem. -- see shy jo signature.asc Description: Digital signature
