Re: Multiarching perl
Niko Tyni <ntyni@debian.org> writes:
> 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.
That's a good point. I didn't think of that.
> Maybe something like this?
I like this proposal, in general. This deals with all of the common
issues that I can think of, provided that aptitude handles the Breaks
properly during an upgrade. Although the Breaks does make me nervous.
> (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'?)
What if we do this: stop providing perlapi frm perl-base and instead have
perl provide perlapi? Otherwise, keep the dependencies and Multi-Arch
designations the same. This means that anything that needs the Perl API
will have to pull in the full standard perl package, but I think that's
reasonable. And only one version of perl can be installed at a time, so
that takes care of the issue of embedding programs losing their modules.
The hard part there is upgrades, since you can't have both perlapis
installed at the same time, which means that all XS and embedding stuff
has to go at once during an upgrade. But I think that's currently true,
right?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: