[arch-dev-public] Packages added to todo list 'Perl 5.22'

[Anatol Pomozov]

Hi

On Tue, Jun 2, 2015 at 12:17 PM, Florian Pritz <bluewind at xinu.at> wrote:
>
> On 02.06.2015 19:47, Gaetan Bisson wrote:
> > What if I want perl to be in optdepends, not depends?
>
> Even if it is possible to put a versioned entry in optdeps (I don't
> know), it wouldn't help really because pacman doesn't actually check
> those. Just omit it and rebuild as always.
>
> I've now also updated the TODO list so this is hopefully a bit clearer.


This template makes pkgbuild file more verbose and complicated than it
should be.

> The reason behind this dep is that perl binary modules only work with
> the abi/api of the perl used to build. As it happens minor releases
> didn't break abi/api so far, but major ones do and normally perl prints
> a nice error telling you about the issue.
>
> Sadly, last year it segfaulted and when you tried to track down which
> module actually caused the segfault you could easily get on a wrong path
> and I got quite a few bogus bug reports until I finally tracked it to
> one package being rebuilt against the wrong repo, a couple people
> running locally built modules from cpan and some having aur packages
> that were not rebuilt.


The problem with mismatched shared libraries comes from AUR and CPAN
packages. Adding the template to packages in official Arch repo will
not solve this problem at all.

Better way to handle the Perl major release ABI change is to provide
users a script that finds all perl libraries not belonging to official
packages and asks user to reinstall that packages.



Another thing that adds headache to perl major updates is the fact
that /site_perl (place where CPAN installs packages) comes before
/vendor_perl (place where Pacman installs packages) in library load
path. Following scenario happened quite a lot during the last perl
upgrade:
- user installs application foo that uses perl-bar
- user accidentally installs perl-bar from system CPAN
- perl major upgrade happens, user receives new perl and new perl-bar.
It is expected that app works fine as its Arch dependencies are
correct and up-to-date.
- user runs 'foo' and gets SIGSEGV because perl loads outdated
perl-bar from /site_perl

It makes more sense to put /vendor_perl before /site_perl. Packages
installed by pacman should have higher priority than users' package.

Even better if installing system packages from CPAN gets discouraged.
Non-pacman system installation brings more troubles than good.

> I hope this dep will make it easier in the future (well once aur
> packages adopt the template).
>
>
> If you have an idea how this could be solved for optdeps I'd be happy to
> hear it.
>