Re: [arch-dev-public] Packages added to todo list 'Perl 5.22'
[2015-06-02 08:10:43 -0000] Arch Website Notification:
Todo list information: Name: Perl 5.22 URL: https://www.archlinux.org/todo/perl-522/ Creator: Florian Pritz Description: Include the following line at the end (inside) of each package() function:
# template input; name=perl-binary-module-dependency;
Then run makepkg-template and build as normal. Push to staging.
What if I want perl to be in optdepends, not depends? Is there a clean way to do that with templates? Cheers. -- Gaetan
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. 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. 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.
[2015-06-02 21:17:03 +0200] Florian Pritz:
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.
Thanks! -- Gaetan
Hi
On Tue, Jun 2, 2015 at 12:17 PM, Florian Pritz
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.
On 07.06.2015 15:38, Anatol Pomozov wrote:
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.
There was also one package that was rebuilt against the wrong repo last year and if I can easily prevent this issue and also help AUR users or those that build from CPAN to detect their own problems I'd rather do that. After all I also created libdeps in makepkg...
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.
I guess I could add that to my script indeed. Thanks for the idea.
It makes more sense to put /vendor_perl before /site_perl. Packages installed by pacman should have higher priority than users' package.
Nobody will expect that behaviour. I'm not going to change this (if it's even possible).
Even better if installing system packages from CPAN gets discouraged. Non-pacman system installation brings more troubles than good.
Agreed.
participants (3)
-
Anatol Pomozov
-
Florian Pritz
-
Gaetan Bisson