[Build-common-hackers] Bug#525436: Bug#525436: cdbs: distutils not installing into non-python-named package

[Jonas Smedegaard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Hi Martin,

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 
>packages.

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 
releases.


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

- -- 
* 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)

iEYEAREDAAYFAkooensACgkQn7DbMsAkQLhxfwCeNj/1XThMS2EQlKp6YW0AIGOw
S0kAn1Nh96ZcdO1ST9PeiqiQoDhrlHgY
=b2Q4
-----END PGP SIGNATURE-----