[Build-common-hackers] Bug#577580: closed by Jonas Smedegaard <dr at jones.dk> (Bug#577580: fixed in cdbs 0.4.81)
debian at onerussian.com
Wed May 5 19:17:49 UTC 2010
ho ho -- now I am getting better comprehension of what you were
delivering to me in:
> I suspect that it only worked in the past because a single version was
> supported (due to your limiting to at least 2.5 and Debian only
> relatively recently introducing 2.6).
I was building fresh nipy and found that only 2.5 libraries were generated
within -lib* packages. Indeed, in nipy we didn't have previously any libraries
for 2.6 BUT in mvpa we got everything just fine with previous versions of cdbs
and similar setup:
$> acpolicy python-mvpa-lib
*** 0.4.4-1 0
900 http://debian.lcs.mit.edu squeeze/main Packages
901 http://debian.lcs.mit.edu sid/main Packages
500 http://neuro.debian.net squeeze/main Packages
500 http://neuro.debian.net sid/main Packages
$> dpkg -L python-mvpa-lib | grep smlrc.so
But with current CDBS, building nipy I get only 2.5 ...
As to me it is a really serious concern -- there is a plentiful of packages
(and ever growing number with cython becoming more popular) where having both
"any" (-lib) and "all" Architectures is the way to go to don't pollute
architecture-dependent binary packages with arch-independent .py files.
I've tried to come up with a blunt workaround having following line after
# Ensure building for all Python versions despite having both arch and
# indep binary packages at ones
cdbs_python_build_versions := $(cdbs_python_supported_versions)
but that had no effect (probably decision is done somewhere prior to that
in any case, for me all this sounds like a regression... not sure what I could
do... if you think it would be too long to fix it up, I guess I would need to
Thanks in advance for reply.
On Wed, 05 May 2010, Yaroslav Halchenko wrote:
> Hi Jonas,
> Since I wasn't in addressee of your replies I did not receive any of them
> unfortunately. Just now found your replies on the web -- thanks. But
> could you address one of them for me?
> > Oh, and please only declare DEB_PYTHON_MODULE_PACKAGES (not
> > DEB_PYTHON_MODULE_PACKAGE too, and even with a different content - that
> > is certainly asking for trouble!).
> well -- the reason for all this is simply to make it work with cdbs
> present in lenny, for which we would have easy ways to backport without
> any patching the packaging (although I am yet to check if I can easily
> backport nipy in particular but this approach worked fine for other
> packages ;) forgotten what stopped me before)
> why should it be seeking for a trouble if nothing in cdbs seems to rely
> on that variable as far as I can see?
> what would be a way to conditionally define one or another (i.e. is
> there a CDBS_VERSION variable exposed may be suitable for comparison?)
> Thanks in advance
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
More information about the Build-common-hackers