-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, Apr 25, 2009 at 10:42:43AM +0200, Martin Pitt wrote:
>Jonas Smedegaard [2009-04-25 9:36 +0200]:
>> In other words, the problem is not that python install rule does no
>> longer get invoked, but that it now gets invoked in parallel (or in
>> undefined order of) other install/* rules.
>
>So if I first include distutils.mk and then define an "install/foo::"
>rule, my own rule isn't guaranteed to be invoked later than the
>distutils ones? I always understood "::" as an "append" operator, not
>"throw it into the set". It's entirely possible that I was wrong all
>the time, of course.
I might be wrong, but yes, my understanding of :: rules is that even if
they often in practice run in the order defined, that is not ensured.
Besides, ideally CDBS snippets should not require to be declared in a
specific order, even if some make expressions really do keep order -
CDBS should try to avoid those, then (as is the case if ifeq).
>> install/calibre:: calibre-fixup
>> calibre-fixup:
>> rm -r ...
>
>I don't understand how this would help? Wouldn't this mean that
>calibre-fixup would run _before_ install/calibre (since it is now a
>dependency), thus aggravating the problem even further?
Stupid me - above is completely upside down. The following should work:
common-binary-arch common-binary-indep:: calibre-fixup
calibre-fixup: install/calibre
rm -r ...
Or to be exact, above works using buildcore.mk, and I believe also using
python-distutils.mk and debhelper.mk - if using other snippets too, you
may need to adjust to the additional rules you want it to be invoked
in-between.
>> Still, from the perspective of this CDBS backwards-compatibility bug,
>> above is only a workaround, not "calibre approach is wrong".
>
>If calibre is the only (or amongst very few) packages which break
>because they used the install target wrongly, I'm fine with keeping
>current cdbs and fixing calibre's debian/rules accordingly.
>
>Basically, I need to do a cleanup at a point when setup.py install was
>run already, but dh_install* etc. didn't start yet. The reason is that
>the extra libraries must not go into the .debs, and doing the cleanup
>after all the dh_* magic makes it much harder to ensure that none of
>the dh_* stuff copied the files to anywhere.
Makes sense. As already said, it is not exactly wrong of you to use the
install/* target, but as it really is a "post-install" routine it makes
better sense to treat it as such.
Help investigating if any other package uses python-distutils.mk and add
custom install/* rules is much appreciated!
Kind regards,
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkny2qEACgkQn7DbMsAkQLhGWwCdEzZPvyLuvkUJE9ywT8JLhJuh
l4AAn1f/A3O7ouetBjCDqlXz4CiJFsHV
=5uxh
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
