Re: Multiarching perl
On Wed, Aug 08, 2012 at 12:46:12PM -0700, Russ Allbery wrote:
> Niko Tyni <firstname.lastname@example.org> writes:
> > (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'?)
As noted, there are the few pseudo-essential XS module packages
that wouldn't fit this. We also need to consider the needs of d-i,
the Debian installer, which has perl-base but not perl and needs
liblocale-gettext-perl et al.
Instead, I may have a better idea. Mandating that applications embedding
perl (that is, linking against libperl) have to Depend on perl would have
the same effect of disallowing multiple libperls outside the upgrade
AFAICS. Such a requirement doesn't seem very onerous to me, and as a
side effect it guarantees the availability of the full standard library.
> 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.
As above, I'm afraid this isn't reasonable. It also seems
rather intrusive to me.
> 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,
Yes, all XS modules must currently be upgraded along with major Perl
On Wed, Aug 08, 2012 at 03:15:57PM -0700, Russ Allbery wrote:
> I wonder if we should bite the bullet and bless a small number of
> particularly critical Perl XS modules in a way that treats them
> differently than the vast majority of other modules and, for those modules
> only, version the package name. In other words, for these sorts of Perl
> XS modules that are effectively pseudo-essential, have a libuuid-perl5.14
> and libuuid-perl5.12, both of which depend only on libperl5.14 and
> libperl5.12 and not on perlapi-5.14.2, and a libuuid-perl metapackage that
> changes which version it depends on when we do a Perl transition. That
> way, you would get both versions of libuuid-perl installed during the
> upgrade transition.
This would indeed be doable. It's not very pretty and I'm not convinced
quite yet that it's necessary but it's certainly worth considering.
I suppose I should do some experimenting based on all this.
Will see if I can find the time.
Thanks for the input so far, and further thoughts welcome of course!
Niko Tyni email@example.com