[Build-common-hackers] Bug#525436: Bug#525436: cdbs: distutils not installing into non-python-named package
dr at jones.dk
Fri Jun 5 01:52:59 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
On Mon, Apr 27, 2009 at 08:34:44AM +0200, Martin Pitt wrote:
>Jonas Smedegaard [2009-04-25 14:01 +0200]:
>> The problem is another: calibre relied on python-distutils installing
>> into topmost binary package declared in debian/control.
>Actually this was what I specifically wanted to avoid. Since it is a
>multi-binary package, I'd expect cdbs autotools/distutils to install
>into debian/tmp/, and using dh_install etc. to install into binary
I just reread your last email and realize that possibly you
misunderstood my point above:
python-distutils.mk has been broken since the implementation of the new
Python policy: It could only support a single Python build environment,
looking only at the topmost non-doc and non-dev package to resolve if
the Python build should be architecture-dependent or not.
Recent changes un-fix this, supporting multiple builds from one source,
either multiple variants of a single module or mutiple modules shipped
in one tarball. Or the core mechanism to support it is there - not all
possible features are applied yet.
What triggers this bug is that you have a package that contains both an
arch-all and an arch-any package, with the arch-all listed first.
cdbs 0.4.52 would just search from the top and pick "calibre" as the
"target package", which means it would use that to - wrongly, it seems -
resolve that the Python build should be done binary-independent.
cdbs 0.4.54 would look for any arch-dependent packages first and pick
"calibre-bin" as the "target package", leading to slightly different
build commands but also the build process would be tied to
"calibre-bin". You can still install into debian/tmp, and you can still
move it from there to the "calibre" package.
So this is not about $DEB_DESTDIR being debian/$(curpkg) instead of
debian/tmp, but about resolving which single binary package should be
treated as the (one and only) Python package.
>With that, I can do the necessary steps in this order:
> 1. upstream install into debian/tmp/
> 2. weed out the files which must be purged from debian/tmp/
> 3. Let cdbs do its dh_* magic
>If I move 2. past 3., the bad files are spread amongst all binary
>packages (potentially), so cleaning is a bit more difficult.
I do not suggest to avoid debian/tmp.
>> Adding the following (either above or below snippet inclusions -
>> order does not matter) makes the package build corectly:
>> DEB_PYTHON_MODULE_PACKAGES = calibre
>That would indeed be a bit weird to specify. I think I'll just move
>the stuff to binary-install/calibre then, if you think that's the
>right thing to do.
Correction: Setting above makes your installation work as before, but
the build commands are slightly wrong (can't say for sure if the result
is any different).
The better approach is to a) change your rules files to use calibre-bin
as main build chain, and b) list calibre-bin topmost in debian/control
so that your package behaves the same with both pre and post 0.4.52 cdbs
Still not sure how to "fix" this bug, as it makes little sense to me to
revert to the earlier broken behavior. :-/
Hope this makes sense (it took the whole night to write!).
* 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)
-----END PGP SIGNATURE-----
More information about the Build-common-hackers