Re: Multiarching perl
Sorry for the delay! I've been mostly offline on a family vacation.
On Sun, Jul 22, 2012 at 05:59:20PM -0700, Russ Allbery wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
> > Niko Tyni wrote:
>
> >> Yes, it's all to do with that. The perl-base package is Essential:yes,
> >> so it needs to stay functional even when its dependencies are not
> >> configured. If libperl.so.$VERSION was in a separate package, upgrading
> >> either of the libperl package or the perl-base package would
> >> potentially break /usr/bin/perl.
> > libperl-$VERSION-base: ships libperl.so.$VERSION
> > perl-base: Pre-Depends: libperl-$VERSION-base
I don't understand the rationale for the -base part
in libperl-$VERSION-base here. What's the gain of splitting
the libperl$VERSION package further?
> I was going to suggest that too -- it *seems* like it should work. Is the
> problem that libperl doesn't always change SONAMEs when making changes
> that might break the Perl binary itself (as opposed to external programs
> that embed it)? Otherwise, it should be possible to have multiple
> co-installable libperl binary packages and have the perl binary itself
> pick up whichever one matches, so during upgrades both will be on the
> system for a while.
Yes on pretty much all of this.
I agree that a Pre-Depends should be enough. However, I'm not sure if
we can trust minor version upgrades of libperl (say 5.16.1 -> 5.16.2)
to keep full compatibility for /usr/bin/perl. I could imagine
it using internal interfaces that change.
OTOH, perlpolicy.pod currently says
Patches that break binary compatibility are not acceptable.
for maintenance branches, so I may be overly paranoid.
I suppose this needs to be checked upstream.
Major version upgrades should indeed not be a problem for /usr/bin/perl
if libperl5.14 and libperl5.16 are co-installable.
However, if libperl5.* are co-installable outside the upgrade phase, the
perlapi-* ABI concept breaks. If we have perl-base at 5.16 but an
application linking against libperl5.14, the latter isn't going to see
any installed XS modules as those have been upgraded along with perl-base.
Maybe something like this?
(Note the Breaks: libperl5.14 in perl/5.16.0-Y. I'm assuming
that any application needing XS modules ends up depending on perl
somehow. Not sure if this is acceptable. Maybe mandate that
all XS module packages have to depend on 'perl'?)
# contains just /usr/bin/perl linking against libperl.so.5.14
Package: perl-base
Version: 5.14.2-X
Provides: perlapi-5.14.2
Pre-Depends: libperl5.14
Essential: yes
Multi-Arch: foreign
# contains libperl.so.5.14, libperl.so.5.14.2, and
# the parts of the standard library currently in perl-base
Package: libperl5.14
Version: 5.14.2-X
Multi-Arch: same
Depends: lib6 etc.
# contains the rest of the standard library in arch-specific paths
# Arch:all perl-modules omitted for clarity
Package: perl
Version: 5.14.2-X
Depends: perl-base (= 5.14.2-X)
Multi-Arch: same
# contains just /usr/bin/perl linking against libperl.so.5.16
Package: perl-base
Version: 5.16.0-Y
Provides: perlapi-5.16.0
Pre-Depends: libperl5.16
Multi-Arch: foreign
Essential: yes
# contains libperl.so.5.16, libperl.so.5.16.0, and
# the parts of the standard library currently in perl-base
Package: libperl5.16
Version: 5.16.0-Y
Multi-Arch: same
Depends: lib6 etc.
# contains the rest of the standard library in arch-specific paths
# Arch:all perl-modules omitted for clarity
Package: perl
Version: 5.16.0-Y
Depends: perl-base (= 5.16.0-Y)
Breaks: libperl5.14
Multi-Arch: same
--
Niko Tyni ntyni@debian.org
Reply to: