* 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:
pgpkqHQfkWI7n.pgp
Description: PGP signature