Bug#639341: dh: cannot override binary-arch and binary-indep selectively
On Fri, Sep 09, 2011 at 05:44:44PM -0400, Joey Hess wrote: Yann Dirson wrote: In fact, adding a last override prevents this strange behaviour: | binary: binary-arch binary-indep ; Well then, are you *sure* you have v9 enabled? Because #629139 was all about avoiding the need for exactly that dependency, in v9. yann@home:tulip-git (patches)$ cat debian/compat 9 You can fetch the tulip_3.6.0dfsg-2 source from sid, and just comment that line: $ script -c 'fakeroot ./debian/rules build' typescript.build [...] $ script -c 'fakeroot ./debian/rules binary' typescript.binary [...] $ grep ^dh_install typescript.binary dh_install --fail-missing dh_install --fail-missing dh_install --fail-missing dh_install: cp -a debian/tmp/usr/share/man/man1/tulip.1 debian/tulip//usr/share/man/man1/ returned exit code 1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Yann Dirson wrote:
$ grep ^dh_install typescript.binary
dh_install --fail-missing
dh_install --fail-missing
dh_install --fail-missing
dh_install: cp -a debian/tmp/usr/share/man/man1/tulip.1
debian/tulip//usr/share/man/man1/ returned exit code 1
So why is it running 3 times? The first is install-arch, the second is
in install-indep (during which dh_prep is run and deletes the files
dh_install -a expects in debian/tmp), and the third seems unnecessary.
$sequences{'install'} = [rules(build), rules(install-arch),
rules(install-indep), @i];
Introduced in d63e08f7ced8f182355038c52babf2f99014f04b. This seems less
correct when there is an install-arch, or an install-indep, or neither,
but noth both.
Perhaps the other patch in #634784 should have been applied instead.
That avoids this failure.
Or, perhaps the @i at the end of the line wants removing?
That also avoids this failure and I've verified it to not change
the sequence otherwise, when install-arch and/or install-indep are not present.
PS, the explicit install: install-arch install-indep dependency
happened to avoid this bug, because it causes make to run
dh install-arch, then dh install-indep, and when it finally
runs dh install, it can see that it has nothing to do.
--
see shy jo
signature.asc
Description: Digital signature
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
On Thu, Sep 08, 2011 at 06:01:54PM -0400, Joey Hess wrote:
Yann Dirson wrote:
On Thu, Sep 08, 2011 at 04:09:42PM -0400, Joey Hess wrote:
Yann Dirson wrote:
Hm, having configure step as part of the build actions, as opposed to
being actions of a configure-specific target like has been done since
a number of years, would probably be useful to mention in the dh
manpage.
I'm not familiar with such a target.
Well, the kind of config.status target, that precisely allows the
configure script to be run only once.
Isn't that mostly done as a stamp target, not a target to be called?
Right, using config.status as a stamp was (maybe is still ?) quite
common.
dh avoids running dh_auto_configure more than once on its own.
Is it doing so using *.debhelper.log ? What I have observed seem
quite similar to the behaviour described in #604563, with
dh_auto_configure -a being run for build-arch, and later
dh_auto_configure -i being run for build-indep. Unless some special
measures have been taken, like the one Roger suggested in
http://bugs.debian.org/604563#20.
Maybe mention (at least it is how I understand it) that foo depends
on both foo-binary and foo-arch, whether the ordering of -binary
and -arch is specified or if the user should avoid to rely on the
order, and if so a suggested test workflow to ensure that
(eg. dh_clean debian/rules binary-arch dh_clean debian/rules
binary-indep - if you can confirm that is supposed to check what I
expect it to).
And maybe insist on the fact that because of this, binary does not
depend on build.
I don't think that any of that is accurate, to the extent I understand
what you're trying to say.
Argh :)
Let's try to pinpoint where we misunderstand each other.
* the no magic aspect implies that instead of talking depends,
which sorta implies {-binary,-arch,} targets, I should rather talk
about sequences, but still, sequences chain each other in a way
that is not unlike make-targets dependencies, right ?
* with this, is the sequence chaining I described, with
{build,install,binary}{,-arch,-indep} correct ? Possibly not in the
case of my binary: binary-arch binary-indep expectation, as
demonstrated by the problem with my rules file below. Looks like an
explanation of what dh binary really does would be helpful.
* do you find the suggested test line above makes no sense ? At least
I have found the idea quite useful in checking whether I had reached
a usable stage in my build process.
* anything else which did not look accurate ?
|install-arch:
| install -D debian/tulip.1 debian/tmp/usr/share/man/man1/tulip.1
| dh $@
This doesn't work because dh is not magic; it cannot do anything before
it is run. So make rules your install command, and then it runs dh,
which finally gets a chance to ensure build-arch is run.
Yes, I see - my mind has probably been warped by build tookits in
which we include Makefile snippets, and which can thus provide such
magic... Feels like hitting some sort of limitation of the
no-include approach (which has other advantages, I admit).
* I cannot insert my installs _after_ dh $@, since dh_prep will nuke
it
* I cannot insert them _before_ it, since dh_install would run first
* I have no arch-specific override to put them where I'd like to
Hm, I have made some progress, harnessing the debhelper log, with
following debian/rules:
| %:
| dh $@ --parallel
| override_dh_auto_configure:
| dh_auto_configure -- -DCMAKE_SKIP_RPATH:BOOL=YES
| build-arch:
| dh $@
| docbook-to-man debian/tulip.sgml debian/tulip.1
| build-indep:
| $(MAKE) -C obj-* doc
| install-indep: build-indep
| dh_prep -i
| mkdir -p debian/tmp/usr/share/doc/tulip-doc
| set -e; for d in common userHandbook developerHandbook doxygen; do \
| cp -a obj-*/docs/$$d debian/tmp/usr/share/doc/tulip-doc/ ;\
| done
| dh_auto_install -- -C docs
| dh $@
| install-arch: build-arch
| dh_prep -a
| install -D debian/tulip.1 debian/tmp/usr/share/man/man1/tulip.1
| dh $@
| override_dh_install:
| dh_install --fail-missing
| override_dh_auto_clean:
| dh_auto_clean
| rm -f debian/tulip.1
Turns out it seems to work pretty well for binary-arch and
binary-indep... except that dh_install fails to find the manpage... on
its 3rd run. It gets run for -arch and -indep (without getting the -a
or -i flag, BTW, did I miss something in my override ?, within easily
identifiable sequences of dh_ commands that get passed -a and -i), and
then a 3rd time within a sequence od dh_ commands that get passed
-O--parallel, as part of target binary as shown by:
| cp: cannot stat `debian/tmp/usr/share/man/man1/tulip.1': No such file or
directory
| dh_install: cp -a debian/tmp/usr/share/man/man1/tulip.1
debian/tulip//usr/share/man/man1/ returned exit code 1
| make[1]: *** [override_dh_install] Error 2
| make[1]:
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
On Fri, Sep 09, 2011 at 10:28:45PM +0200, Yann Dirson wrote: Turns out it seems to work pretty well for binary-arch and binary-indep... except that dh_install fails to find the manpage... on its 3rd run. It gets run for -arch and -indep (without getting the -a or -i flag, BTW, did I miss something in my override ?, within easily identifiable sequences of dh_ commands that get passed -a and -i), and then a 3rd time within a sequence od dh_ commands that get passed -O--parallel, as part of target binary as shown by: | cp: cannot stat `debian/tmp/usr/share/man/man1/tulip.1': No such file or directory | dh_install: cp -a debian/tmp/usr/share/man/man1/tulip.1 debian/tulip//usr/share/man/man1/ returned exit code 1 | make[1]: *** [override_dh_install] Error 2 | make[1]: Leaving directory `/work/yann/deb/tulip/tulip-git' | make: *** [binary] Error 2 In fact, adding a last override prevents this strange behaviour: | binary: binary-arch binary-indep ; That leaves the % catch-all rule only used by the build-* targets. Is that just my own personal style, of relying too much on make deps for the taste of the dh wrapper ? Best regards, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Yann Dirson wrote:
Is it doing so using *.debhelper.log ? What I have observed seem
quite similar to the behaviour described in #604563, with
dh_auto_configure -a being run for build-arch, and later
dh_auto_configure -i being run for build-indep. Unless some special
measures have been taken, like the one Roger suggested in
http://bugs.debian.org/604563#20.
Special measures have been taken to avoid duplicate runs, but only when
running debian/rules binary.
Running back-to-back debian/rules binary-arch; debian/rules binary-indep
is not a common case and remains unoptimised IIRC.
Maybe mention (at least it is how I understand it) that foo depends
on both foo-binary and foo-arch, whether the ordering of -binary
and -arch is specified or if the user should avoid to rely on the
order, and if so a suggested test workflow to ensure that
(eg. dh_clean debian/rules binary-arch dh_clean debian/rules
binary-indep - if you can confirm that is supposed to check what I
expect it to).
And maybe insist on the fact that because of this, binary does not
depend on build.
I don't think that any of that is accurate, to the extent I understand
what you're trying to say.
Argh :)
Let's try to pinpoint where we misunderstand each other.
* the no magic aspect implies that instead of talking depends,
which sorta implies {-binary,-arch,} targets, I should rather talk
about sequences, but still, sequences chain each other in a way
that is not unlike make-targets dependencies, right ?
* with this, is the sequence chaining I described, with
{build,install,binary}{,-arch,-indep} correct ? Possibly not in the
case of my binary: binary-arch binary-indep expectation, as
demonstrated by the problem with my rules file below. Looks like an
explanation of what dh binary really does would be helpful.
No, to quote Douglas Adams, it's entirely unlike tea.
The right mental model is that dh looks at what it's been asked to do,
looks at what has already been done, looks at the rules file, generates
a sequence of commands, and runs them.
* do you find the suggested test line above makes no sense ? At least
I have found the idea quite useful in checking whether I had reached
a usable stage in my build process.
I don't know what it's supposed to do. Running dh_clean manually is
sometimes useful, but I would not particularly suggest it as part of
some test regimen.
It gets run for -arch and -indep (without getting the -a or -i flag,
BTW, did I miss something in my override ?)
dh has to pass options into override targets via DH_INTERNAL_OPTIONS.
Turns out it seems to work pretty well for binary-arch and
binary-indep... except that dh_install fails to find the manpage... on
its 3rd run. [...] as part of target binary
| cp: cannot stat `debian/tmp/usr/share/man/man1/tulip.1': No such file or
directory
| dh_install: cp -a debian/tmp/usr/share/man/man1/tulip.1
debian/tulip//usr/share/man/man1/ returned exit code 1
| make[1]: *** [override_dh_install] Error 2
| make[1]: Leaving directory `/work/yann/deb/tulip/tulip-git'
| make: *** [binary] Error 2
I can't really debug it from this amount of information unfortunatly.
I don't know why it would be run 3 times, that does not seem like
a normal build situation.
- binary-arch/indep overrides still not used under v9 (msg #37): need
attempting to reproduce the config, since we ended up investigating
other directions
| Unfortunately, switching to v9 here does not help - or ar least
| --no-act says so. I attach my current diff from the tulip 3.6.0dfsg-1
| currently in sid.
# no attachment actually attached
I don't see how this is a potential bug report, but then I'm not a mind
reader.
- me confused on the --no-act example (#47): manpage could mention
that it only list the commands that would be run by dh foo, that
would be run with current state of the build tree.
- implications of the *.debhelper.log files should be described
outside of the internals section, since they are important to
sequencing (#62)
I'm always happy to make minor tweaks to man pages to eliminate
confusing wording. As long as I can find ways that does not bury the
user under a pile of obvious or irrelevant detail. File bugs.
- Possibly missing the higher-level debugging tool I was dreaming of,
that would tell what commands each of the dh calls would run without
requiring the user to set his build tree to the state in which it
would be when the tool will be run (with some luck this sentence
will make sense to someone other than me ;). Not sure how that
could be achieved - possibly relying on make -dn to see what
commands would be run, and simulate how the succession of dh
sequences will do, keeping track of the debhelper.log files - not a
small task, I fear, and probably not without various problems. I
guess this is the cost of handling sequencing outside of make...
dh should
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Yann Dirson wrote: In fact, adding a last override prevents this strange behaviour: | binary: binary-arch binary-indep ; Well then, are you *sure* you have v9 enabled? Because #629139 was all about avoiding the need for exactly that dependency, in v9. -- see shy jo signature.asc Description: Digital signature
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Yann Dirson wrote: Why not just run dh build-arch in the build-arch target? Ah, I think I'm starting to understand the big picture - that seems to be OK for build-arch. Now I'm still unclear about build-indep. The original package (3.6.0dfsg-1) does not separate them, and uses: |override_dh_auto_build: |build-arch: | dh_auto_build | dh_auto_build -- doc | docbook-to-man debian/tulip.sgml debian/tulip.1 Intuitively, I'd like to use something like the following, which does not appear to be possible AFAIU: |override_dh_auto_build_indep: | dh_auto_build -- doc This idea has been considered before and did not seem worth doing at the time. See #604563 All you seem to need is: build-indep: dh_auto_configure make doc docbook-to-man debian/tulip.sgml debian/tulip.1 And something similar is going to happen with install, with the following I'd like to split in a similar way: |override_dh_auto_install: | dh_auto_install | dh_auto_install -- -C docs What do you think ? install-indep: dh_auto_install -- -C docs dh install-indep -- see shy jo signature.asc Description: Digital signature
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
On Thu, Sep 08, 2011 at 02:20:37PM -0400, Joey Hess wrote: Yann Dirson wrote: Why not just run dh build-arch in the build-arch target? Ah, I think I'm starting to understand the big picture - that seems to be OK for build-arch. Now I'm still unclear about build-indep. The original package (3.6.0dfsg-1) does not separate them, and uses: |override_dh_auto_build: |build-arch: | dh_auto_build | dh_auto_build -- doc | docbook-to-man debian/tulip.sgml debian/tulip.1 Intuitively, I'd like to use something like the following, which does not appear to be possible AFAIU: |override_dh_auto_build_indep: | dh_auto_build -- doc This idea has been considered before and did not seem worth doing at the time. See #604563 Well, that was a long read :) All you seem to need is: build-indep: dh_auto_configure make doc docbook-to-man debian/tulip.sgml debian/tulip.1 Hm, having configure step as part of the build actions, as opposed to being actions of a configure-specific target like has been done since a number of years, would probably be useful to mention in the dh manpage. In fact the list of supported sequences that one can get by calling dh foo would be good to have in the manpage. Similarly, the precise relation between build/install/binary and their -arch/-indep counterparts could be more precisely described: the discussion in #604563 about whether the latter would be run in a row or not probably shows that things are not easy. And I do like Roger Leigh's override_dh_auto_configure: debian/build/config.status idiom. But appart that it could be good to add to examples, too, I can't get it to work with cmake, since the build dir is named obj-$some_undocumented_arch_var (variable which I suspect to only be accessible from perl, correct ?) And something similar is going to happen with install, with the following I'd like to split in a similar way: |override_dh_auto_install: | dh_auto_install | dh_auto_install -- -C docs What do you think ? install-indep: dh_auto_install -- -C docs dh install-indep Ah... relying on the .debhelper.log files. Takes time to assimilate this idea as well - again sorely missing as a example :) Best regards, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Yann Dirson wrote: Hm, having configure step as part of the build actions, as opposed to being actions of a configure-specific target like has been done since a number of years, would probably be useful to mention in the dh manpage. I'm not familiar with such a target. In fact the list of supported sequences that one can get by calling dh foo would be good to have in the manpage. Perhaps in the first paragraph like it does now? Similarly, the precise relation between build/install/binary and their -arch/-indep counterparts could be more precisely described I believe that the second paragraph of the man page does so, to the extent that users of dh need to worry about it. Unless it's somehow not clear that eg binary is a union of binary-arch and binary-indep. -- see shy jo signature.asc Description: Digital signature
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
On Thu, Sep 08, 2011 at 04:09:42PM -0400, Joey Hess wrote: Yann Dirson wrote: Hm, having configure step as part of the build actions, as opposed to being actions of a configure-specific target like has been done since a number of years, would probably be useful to mention in the dh manpage. I'm not familiar with such a target. Well, the kind of config.status target, that precisely allows the configure script to be run only once. In fact the list of supported sequences that one can get by calling dh foo would be good to have in the manpage. Perhaps in the first paragraph like it does now? /me hides Similarly, the precise relation between build/install/binary and their -arch/-indep counterparts could be more precisely described I believe that the second paragraph of the man page does so, to the extent that users of dh need to worry about it. Unless it's somehow not clear that eg binary is a union of binary-arch and binary-indep. Maybe mention (at least it is how I understand it) that foo depends on both foo-binary and foo-arch, whether the ordering of -binary and -arch is specified or if the user should avoid to rely on the order, and if so a suggested test workflow to ensure that (eg. dh_clean debian/rules binary-arch dh_clean debian/rules binary-indep - if you can confirm that is supposed to check what I expect it to). And maybe insist on the fact that because of this, binary does not depend on build. To continue with my tulip rules files and my struggle to understand when dh runs what, I am currently trying the following - under the idea that dh install-arch will run dh_install: |build-arch: | dh $@ | docbook-to-man debian/tulip.sgml debian/tulip.1 |install-arch: | install -D debian/tulip.1 debian/tmp/usr/share/man/man1/tulip.1 | dh $@ |override_dh_install: | dh_install --fail-missing However, it fails showing that install-arch does not indeed depend on build-arch, since my install command gets run much too early. This is not what I understood when reading in the last example: dh will arrange for debian/rules build to call your build-indep and build-arch targets. You do not need to explicitly define those dependencies in the rules file when using dh with compatibility level v9. |$ dh_clean fakeroot ./debian/rules binary-arch |dh binary-arch --parallel | debian/rules install-arch |make[1]: Entering directory `/work/yann/deb/tulip/tulip-git' |install -D debian/tulip.1 debian/tmp/usr/share/man/man1/tulip.1 |dh install-arch | debian/rules build-arch |[...] | dh_auto_test -a |docbook-to-man debian/tulip.sgml debian/tulip.1 |make[2]: Leaving directory `/work/yann/deb/tulip/tulip-git' | dh_testroot -a | dh_prep -a | dh_installdirs -a | dh_auto_install -a make[2]: Entering directory `/work/yann/deb/tulip/tulip-git/obj-x86_64-linux-gnu' |[...] |make[2]: Leaving directory `/work/yann/deb/tulip/tulip-git/obj-x86_64-linux-gnu' | debian/rules override_dh_install |make[2]: Entering directory `/work/yann/deb/tulip/tulip-git' |dh_install --fail-missing |cp: cannot stat `debian/tmp/usr/share/man/man1/tulip.1': No such file or directory |dh_install: cp -a debian/tmp/usr/share/man/man1/tulip.1 debian/tulip//usr/share/man/man1/ returned exit code 1 |make[2]: *** [override_dh_install] Error 2 |make[2]: Leaving directory `/work/yann/deb/tulip/tulip-git' |make[1]: *** [install-arch] Error 2 |make[1]: Leaving directory `/work/yann/deb/tulip/tulip-git' |make: *** [binary-arch] Error 2 if now I re-run, it *does* run my command, presumably because now it knows that all the build-arch steps have been done: |yann@home:tulip-git (patches)$ fakeroot ./debian/rules binary-arch |dh binary-arch --parallel | debian/rules install-arch |make[1]: Entering directory `/work/yann/deb/tulip/tulip-git' |install -D debian/tulip.1 debian/tmp/usr/share/man/man1/tulip.1 |dh install-arch | debian/rules override_dh_install |make[2]: Entering directory `/work/yann/deb/tulip/tulip-git' |dh_install --fail-missing I tried to add an install-arch: build-arch dep, but it still causes strange things: |docbook-to-man debian/tulip.sgml debian/tulip.1 |install -D debian/tulip.1 debian/tmp/usr/share/man/man1/tulip.1 |dh install-arch | debian/rules build-arch |make[2]: Entering directory `/work/yann/deb/tulip/tulip-git' |dh build-arch |docbook-to-man debian/tulip.sgml debian/tulip.1 |make[2]: Leaving directory `/work/yann/deb/tulip/tulip-git' | dh_testroot -a | dh_prep -a ... which still nukes my debian/tmp so in short: * I cannot insert my installs _after_ dh $@, since dh_prep will nuke it * I cannot insert them _before_ it, since dh_install would run first * I have no arch-specific override to put them where I'd like to gasp... did I find the reason to add those arch-specific overrides ? Best regards, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Yann Dirson wrote: On Thu, Sep 08, 2011 at 04:09:42PM -0400, Joey Hess wrote: Yann Dirson wrote: Hm, having configure step as part of the build actions, as opposed to being actions of a configure-specific target like has been done since a number of years, would probably be useful to mention in the dh manpage. I'm not familiar with such a target. Well, the kind of config.status target, that precisely allows the configure script to be run only once. Isn't that mostly done as a stamp target, not a target to be called? dh avoids running dh_auto_configure more than once on its own. Maybe mention (at least it is how I understand it) that foo depends on both foo-binary and foo-arch, whether the ordering of -binary and -arch is specified or if the user should avoid to rely on the order, and if so a suggested test workflow to ensure that (eg. dh_clean debian/rules binary-arch dh_clean debian/rules binary-indep - if you can confirm that is supposed to check what I expect it to). And maybe insist on the fact that because of this, binary does not depend on build. I don't think that any of that is accurate, to the extent I understand what you're trying to say. |install-arch: | install -D debian/tulip.1 debian/tmp/usr/share/man/man1/tulip.1 | dh $@ This doesn't work because dh is not magic; it cannot do anything before it is run. So make rules your install command, and then it runs dh, which finally gets a chance to ensure build-arch is run. * I cannot insert my installs _after_ dh $@, since dh_prep will nuke it * I cannot insert them _before_ it, since dh_install would run first * I have no arch-specific override to put them where I'd like to gasp... did I find the reason to add those arch-specific overrides ? Possibly.. that would make a nice bug report. It's not what this bug report was about, is it? -- see shy jo signature.asc Description: Digital signature
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
On Sun, Aug 28, 2011 at 04:51:11PM -0400, Joey Hess wrote: Yann Dirson wrote: Following the last example from the dh manpage, I am trying the following rules file (compat=8). However, it seems to completely ignore the build-* overrides (install fails on manpage install): $ dh build-arch --no-act dh_testdir -a debian/rules override_dh_auto_configure dh_auto_build -a dh_auto_test -a So, looking at this again, I now see that you've misunderstood what dh does with explicit debian/rules targets. Well, I was merely using it as suggested in the manpage: To see what commands are included in a sequence, without actually doing anything: dh binary-arch --no-act An more detailed description of the meaning of sequence in the synopsis, and the interactions with overridden targets like build-arch, could probably have helped. But probably I was confused by the example cited above, which simply does not play well with overriding. When one is going to override the standard targets, what would be useful is to know what exact commands would be overridden. Here running dh build-arch --no-act shows configure/build/test commands; although the status of the auto_configure command is clear to an old-timer like me who is catching up with latest advances in packaging tech, eg. the status of the auto_test command is not so: it looks like it is run as part of the build-arch target proper, but then if I override build-arch I need to re-specify dh_auto_test call explicitely, which is a clear case of problem-inducing copypaste. What about instead allow overriding commands with targets like override_dh_auto_build_indep and override_dh_auto_build_arch ? The dh man page explains it this way -- I think this explaination is clear. Finally, remember that you are not limited to using override targets in the rules file when using dh. You can also explicitly define any of the regular rules file targets when it makes sense to do so. A common reason to do this is when your package needs different build-arch and build-indep targets. For example, a package with a long document build process can put it in build-indep. #!/usr/bin/make -f %: dh $@ build-indep: $(MAKE) docs build-arch: $(MAKE) bins Note that in the example above, dh will arrange for debian/rules build to call your build-indep and build- arch targets. You do not need to explicitly define those dependencies in the rules file when using dh with compatibility level v9. I tried things like: build-arch: dh_auto_build -a docbook-to-man debian/tulip.sgml debian/tulip.1 That does not work, dh_auto_build does not do anything (nor does it report anything under DH_VERBOSE=1). If that's expected, maybe a notice would be useful. But it is unfortunate that it does not work, since that seems to require reimplementing in my build-arch support for $buildpath and --parallel (those that I need, probably among those I have not seen). But trying to go that way: build-arch: $(MAKE) -C obj-* docbook-to-man debian/tulip.sgml debian/tulip.1 ... it looks like the configure step is not run (which I would have assumed from the last manpage example). With that said, if your package still doesn't build, perhaps there's still a bug somewhere.. ... or I'm completely off-tracks :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Yann Dirson wrote: I tried things like: build-arch: dh_auto_build -a docbook-to-man debian/tulip.sgml debian/tulip.1 You're not running dh_auto_configure which dh would normally run here. Why not just run dh build-arch in the build-arch target? -- see shy jo signature.asc Description: Digital signature
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
On Tue, Aug 30, 2011 at 05:59:21PM -0400, Joey Hess wrote: Yann Dirson wrote: I tried things like: build-arch: dh_auto_build -a docbook-to-man debian/tulip.sgml debian/tulip.1 You're not running dh_auto_configure which dh would normally run here. Why not just run dh build-arch in the build-arch target? Ah, I think I'm starting to understand the big picture - that seems to be OK for build-arch. Now I'm still unclear about build-indep. The original package (3.6.0dfsg-1) does not separate them, and uses: |override_dh_auto_build: |build-arch: | dh_auto_build | dh_auto_build -- doc | docbook-to-man debian/tulip.sgml debian/tulip.1 Intuitively, I'd like to use something like the following, which does not appear to be possible AFAIU: |override_dh_auto_build_indep: | dh_auto_build -- doc And something similar is going to happen with install, with the following I'd like to split in a similar way: |override_dh_auto_install: | dh_auto_install | dh_auto_install -- -C docs What do you think ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
On Tue, Aug 30, 2011 at 05:59:21PM -0400, Joey Hess wrote: Yann Dirson wrote: I tried things like: build-arch: dh_auto_build -a docbook-to-man debian/tulip.sgml debian/tulip.1 You're not running dh_auto_configure which dh would normally run here. Why not just run dh build-arch in the build-arch target? Well, I am tempted to think my problems come from the manpage example not doing that in the first place :) Another thing that I feel lacks in the manpage is a user-level description of what the debhelper log tries to achieve. Its details are mentionned in INTERNALS, which is probably not intended to be necessary to read for an understanding of what happenned ?. That is, the dh manpage should probably mentions earlier that dh remembers what dh_* commands have been run. This would allow to explain that one can run things like the following without package-specific actions being overridden with general ones: override_dh_foo: dh_foo -ppblurb whatever dh_foo OTOH I got surprised (although I think I understand what happenned behind the scenes) that running build-arch runs auto_configure only for arch packages, whereas it is for most packages a generic thing, so that running build-indep afterwards cause cmake to be run again. I guess this can cause unwanted rebuilds when one then runs build-arch again. Best regards, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
On Sat, Aug 27, 2011 at 06:14:31PM -0400, Joey Hess wrote: The dh man page also has a caveat just after the example you followed about v9 being needed. Ah OK, I had missed it. notabug? Unfortunately, switching to v9 here does not help - or ar least --no-act says so. I attach my current diff from the tulip 3.6.0dfsg-1 currently in sid. Best regards, -- Yann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Yann Dirson wrote: Following the last example from the dh manpage, I am trying the following rules file (compat=8). However, it seems to completely ignore the build-* overrides (install fails on manpage install): $ dh build-arch --no-act dh_testdir -a debian/rules override_dh_auto_configure dh_auto_build -a dh_auto_test -a So, looking at this again, I now see that you've misunderstood what dh does with explicit debian/rules targets. If debian/rules has a build-arch target and uses dh, then debian/rules build will run dh, which will ensure that the explicit build-arch target is called, instead of performing its normal build-arch sequence. However, this does not change the actual sequence performed by calling dh build-arch. Normally, one would not run dh build-arch to build a package; one would run debian/rules build-arch, and as that is a normal makefile target, it runs normally; dh need not be involved at all. I can see how you could be confused and expect dh build-arch to notice there was an explicit build-arch target and run it instead of its normal sequence, but I do not think that is a useful behavior. And it would break in an example like this one: build-arch: ./pre-build # now the normal dh sequence can do the building dh build-arch The dh man page explains it this way -- I think this explaination is clear. Finally, remember that you are not limited to using override targets in the rules file when using dh. You can also explicitly define any of the regular rules file targets when it makes sense to do so. A common reason to do this is when your package needs different build-arch and build-indep targets. For example, a package with a long document build process can put it in build-indep. #!/usr/bin/make -f %: dh $@ build-indep: $(MAKE) docs build-arch: $(MAKE) bins Note that in the example above, dh will arrange for debian/rules build to call your build-indep and build- arch targets. You do not need to explicitly define those dependencies in the rules file when using dh with compatibility level v9. With that said, if your package still doesn't build, perhaps there's still a bug somewhere.. -- see shy jo signature.asc Description: Digital signature
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
On Fri, Aug 26, 2011 at 08:23:05AM +0200, Gergely Nagy wrote: Yann Dirson ydir...@free.fr writes: Package: debhelper Version: 8.9.4 Severity: normal Following the last example from the dh manpage, I am trying the following rules file (compat=8). However, it seems to completely ignore the build-* overrides (install fails on manpage install): $ dh build-arch --no-act dh_testdir -a debian/rules override_dh_auto_configure dh_auto_build -a dh_auto_test -a I had a similar issue a couple of days ago. For me, putting dh's catch-all rule (%) last in my debian/rules file worked around the problem. Hm, doing that here does not change the behaviour in my case. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Gergely Nagy wrote: I had a similar issue a couple of days ago. For me, putting dh's catch-all rule (%) last in my debian/rules file worked around the problem. If you have a test case for this I would be happy to receive it in a separate bug report. -- see shy jo signature.asc Description: Digital signature
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Yann Dirson wrote: Following the last example from the dh manpage, I am trying the following rules file (compat=8). However, it seems to completely ignore the build-* overrides (install fails on manpage install): v9 This compatibility level is still open for development; use with caution. Changes from v8 are: - dh allows defining custom build, build-arch, and build-indep targets in debian/rules, without needing to manually define the other targets that depend on them. The dh man page also has a caveat just after the example you followed about v9 being needed. notabug? -- see shy jo signature.asc Description: Digital signature
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Joey Hess jo...@debian.org writes: Gergely Nagy wrote: I had a similar issue a couple of days ago. For me, putting dh's catch-all rule (%) last in my debian/rules file worked around the problem. If you have a test case for this I would be happy to receive it in a separate bug report. Hrm, I tried to come up with a simple test case, but couldn't. And apparently, the package in which I did this apparently does not exhibit the problem anymore, either. So must have been something fishy in my environment. But for the record, my problem was that upstream had a build/ directory, and debian/rules build wasn't building, since it found the dir and considered it up-to-date. As a quick workaround, I wanted to add a build-stamp phony target as a dependency to build, and when I put that after the % rule, it didn't work at that time (read: it still didn't build, but considered the directory up-to-date), so I moved it before the cathc-all rule, and voila. However, when I moved the stamp-foo to the end now, it still behaves properly now. So either I fixed something in the packaging that I did not notice, or there was an issue with my environment which went away sometime during the past week. In any case, sorry for the noise. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Package: debhelper Version: 8.9.4 Severity: normal Following the last example from the dh manpage, I am trying the following rules file (compat=8). However, it seems to completely ignore the build-* overrides (install fails on manpage install): $ dh build-arch --no-act dh_testdir -a debian/rules override_dh_auto_configure dh_auto_build -a dh_auto_test -a = #!/usr/bin/make -f # -*- makefile -*- # This has to be exported to make some magic below work. export DH_OPTIONS %: dh $@ --parallel override_dh_auto_configure: dh_auto_configure -- -DCMAKE_SKIP_RPATH:BOOL=YES build-arch: dh_auto_build docbook-to-man debian/tulip.sgml debian/tulip.1 build-indep: dh_auto_build -- doc override_dh_auto_install: dh_auto_install dh_auto_install -- -C docs mkdir -p debian/tmp/usr/share/doc/tulip-doc for d in common userHandbook developerHandbook doxygen; do \ cp -a obj-*/docs/$$d debian/tmp/usr/share/doc/tulip-doc/ ;\ done install -D debian/tulip.1 debian/tmp/usr/share/man/man1/tulip.1 override_dh_install: dh_install --fail-missing override_dh_auto_clean: dh_auto_clean rm -f debian/tulip.1 = (the install target may be to adapt as well when the build-* stuff works) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'oldstable'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38.4 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages debhelper depends on: ii binutils 2.21.52.20110606-2 The GNU assembler, linker and bina ii dpkg-dev 1.16.0.3 Debian package development tools ii file 5.04-5+b1 Determines file type using magic ii html2text 1.3.2a-15 advanced HTML to text converter ii man-db2.6.0.2-2 on-line manual pager ii perl 5.12.4-4 Larry Wall's Practical Extraction ii perl-base 5.12.4-4 minimal Perl system ii po-debconf1.0.16+nmu1tool for managing templates file t debhelper recommends no packages. Versions of packages debhelper suggests: ii dh-make 0.59 tool that converts source archives -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Yann Dirson ydir...@free.fr writes: Package: debhelper Version: 8.9.4 Severity: normal Following the last example from the dh manpage, I am trying the following rules file (compat=8). However, it seems to completely ignore the build-* overrides (install fails on manpage install): $ dh build-arch --no-act dh_testdir -a debian/rules override_dh_auto_configure dh_auto_build -a dh_auto_test -a I had a similar issue a couple of days ago. For me, putting dh's catch-all rule (%) last in my debian/rules file worked around the problem. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
