Re: perl and multi-arch (was: Re: Upcoming Debian multiarch support (amd64, sparc64, s390x, mips64) [affects sarge slightly])

[Bart Trojanowski <bart@jukie.net>]

* Anthony DeRobertis <asd@suespammers.org> [040115 17:48]:
> I'm not quite clear on this point. Let's say there is an 
> architecture-dependent perl library (=modules):
> 
> 	lib-a-perl
> 
> First off, what bit-ness do we build this for? 32- or 64-bit? I assume 
> both. So we have two packages:
> 
> 	lib-a-perl:amd64
> 	lib-a-perl:i386
> 
> Now, I package a perl script, foo, which uses a.pm. It is 
> architecture-independent, so what does it dependency look like? Not 
> lib-a-perl:amd64 or lib-a-perl:i386. It's the same package on every 
> architecture, after all.
> 
> At first glance, it'd copy the architecture, leaving the rather silly 
> Depends: lib-a-perl:all. I guess that'd need to be treated specially.
> 
> But that leaves the problem that while foo certainly doesn't care which 
> lib-a-perl it gets, perl certainly does. Well, lib-a-perl:amd64 is 
> going to depend on perlapi-X and perl:amd64, so I guess that works out 
> technically.

I would see this:

Package: perl
Architecture: amd64

Package: lib-a-perl
Architecture: amd64
Depends: perl:amd64
ABI: amd64

Package: lib-a-perl
Architecture: i386
Depends: perl:i386
ABI: ia32

Package: my-script
Depends: lib-a-perl

Since perl is installed as :amd64, you can see that lib-a-perl:i386 will
never be considered.

> Does apt deal with that mess nicely? That's a huge dependency tree.

It will be slower... but the same argument can be made about adding more
packages.  And on 32bit machines this will not be a problem because apt
will never d/l the binary-amd64 package list.

B.

-- 
				WebSig: http://www.jukie.net/~bart/sig/

Attachment: pgpPv6oWUo082.pgp
Description: PGP signature