[Build-common-hackers] Bug#577580: closed by Jonas Smedegaard <dr at jones.dk> (Bug#577580: fixed in cdbs 0.4.81)

[Yaroslav Halchenko]

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 
python-mvpa-lib:
  Installed: 0.4.4-1
  Candidate: 0.4.4-1
  Version table:
 *** 0.4.4-1 0
        900 http://debian.lcs.mit.edu squeeze/main Packages
        901 http://debian.lcs.mit.edu sid/main Packages
        100 /var/lib/dpkg/status
     0.4.4-1~squeeze.nd1 0
        500 http://neuro.debian.net squeeze/main Packages
     0.4.3-1~sid.nd1 0
        500 http://neuro.debian.net sid/main Packages

$> dpkg -L python-mvpa-lib | grep smlrc.so
/usr/lib/pyshared/python2.5/mvpa/clfs/libsmlrc/smlrc.so
/usr/lib/pyshared/python2.6/mvpa/clfs/libsmlrc/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
include /usr/share/cdbs/1/class/python-distutils.mk

# 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
point)...

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
consider alternatives.

Thanks in advance for reply.

Cheers,
Yarik

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
> Cheers
-- 
                                  .-.
=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     (yoh@|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                   Linux User    ^^-^^    [175555]


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20100505/9d0c8b2d/attachment.pgp>