Hi On Tue, Jun 2, 2015 at 12:17 PM, Florian Pritz <bluewind@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.