Re: perl and multi-arch (was: Re: Upcoming Debian multiarch support (amd64, sparc64, s390x, mips64) [affects sarge slightly])
Anthony DeRobertis <asd@suespammers.org> writes:
> I'm not quite clear on this point. Let's say there is an
> architecture-dependent perl library (=modules):
>
>
> lib-a-perl
Is that just perl code (Architecture: all) or C code interfacing
with perl (Architecture: <arch>). I assume the later.
> 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
The i386 buildd will build lib-a-perl-1.2.3-1_i386.deb and the amd64
buildd will build lib-a-perl-1.2.3-1_amd64.deb. Both upload those to
their respective binary-<arch> dir.
[The <pkg>:<arch> syntax is for special needs and some special depends
(you raised a good example, see below). Normaly you shouldn't need to
specify the arch at all.]
> 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.
I think you found a minor problem here. Not sure if perl modules work
that way but I guess they could.
Package: foo
Architecture: all
Depends: lib-a-perl
Package: lib-a-perl
Architecture: i386
ABI: ia32
Depends: perl
Package: lib-a-perl
Architecture: amd64
ABI: amd64
Depends: perl
Now it becomes intresting. From "Architecture: all" in foo dpkg can't
decide if it needs lib-a-perl:i386 or lib-a-perl:amd64. Both look like
possible candidates.
But Only one perl can be installed and thus only one of the two packages
is actually installable. And the perl use has to match the ABI used in
lib-a-perl. The correct control entries for lib-a-perl should be:
Package: lib-a-perl
Architecture: i386
ABI: ia32
Depends: perl:ia32
Package: lib-a-perl
Architecture: amd64
ABI: amd64
Depends: perl:amd64
> 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.
In the case of extra modules the mechanism used for libraries doesn't
work. The depends is reversed (the lib depending on the binary) and
the 'normal' abi stuff won't work.
Maybe it would be better for perl:amd64 to provide perlapi-X-64 for
the biarch flavour and perlapi-X for everything else. That would keep
compatibility by forcing a few conditional renamings on the depends
lines (every perl module package).
> Does apt deal with that mess nicely? That's a huge dependency tree.
You have to increase the Dynamix MMap size of cause, as usual. You end
up with twice the number of packages (if everything is available for
amd64 and i386) but amd64 should have enough ram and cpu power for
that.
Thanks for raising this example. We have to figure that into the
design process. I guess its back to the drawing board to see if theres
a better method to solve this.
MfG
Goswin
Reply to: