[arch-dev-public] [RFC] Perl configuration revisited
Hi, I've looked around a bit for possible ways to prevent segfault issues like with the upgrade to 5.20.0. I tried adding a version to libperl.so (including setting a soname for the library), but that only helps programs that link to libperl (like weechat). In my (rather short) tests it wouldn't affect perl modules loaded by perl ("use FooBar::Blub;" in a perl script). Dead end IMHO. I also tried adding the major perl version (5.20) to the perl dirs we currently have in /usr/lib. So /usr/share/perl5/vendor_perl would become /usr/share/perl5/vendor_perl/5.20, similar for the others. Perl's default would do something similar, but include the full version which seems overkill since I didn't see a minor update break API. According to pkgfile[1] such a change would affect 117 packages with 112 of those actually having a .so file in there[2]. In case anyone wants to know, the 5 packages are: perl-sgmls stow foomatic-db-engine perl-anyevent perl-common-sense. [1]: pkgfile -r '/usr/lib/perl5/' | wc -l [2]: pkgfile -r '/usr/lib/perl5/.*\.so$' | wc -l This change would remove binary modules from perl's @INC on update (@INC is like $PATH, but for perl modules and contains the vendor_perl path mentioned above amongst others) which is pretty much what we want, except it leads to possibly confusing error messages ("module not found" rather than "libperl.so.$oldversion not found"), but it should prevent future segfaults in case of incompatible libs. Non-binary modules are in /usr/share/perl5/vendor_perl (note share instead of lib) and won't have to be rebuilt on perl upgrades. I don't know why it was originally set up to be non-versioned, but the wiki mentions that the current config is influenced by the Debian's perl policy which probably has different requirements. Unless people think it's a good idea to implement this now (would require a rebuild of ~130 packages) I'm targeting perl 5.22. The change should not require any changes to PKGBUILDs (tested weechat, perl-net-dns and perl-dbi). Any input is welcome, especially possible downsides of my idea.
[2014-06-06 23:55:55 +0200] Florian Pritz:
I also tried adding the major perl version (5.20) to the perl dirs we currently have in /usr/lib. So /usr/share/perl5/vendor_perl would become /usr/share/perl5/vendor_perl/5.20, similar for the others. Perl's default would do something similar, but include the full version which seems overkill since I didn't see a minor update break API.
If the path is entirely up to us, I think something like /usr/share/perl5.20/{core,site,vendor}_perl would make more sense, as the specifics should come last: upstream's default of putting the version at the end looks ugly to my eyes... But then again there might be value getting our packager closer to upstream defaults, so I'll let you decide if the pros outweighs the cons. Cheers. -- Gaetan
-------- Original Message -------- Subject: Perl module installation dirs Date: Tue, 10 Jun 2014 21:51:22 -0400 From: Justin Davis <jrcd83@gmail.com> To: Florian Pritz <bluewind@xinu.at> Here is a short response to your RFC. I cannot post to the arch-dev-public mailing list. The vendor arch specific directory, in accordance with the Arch Way(tm), should stay un-versioned. Why? Not just for principles. The reason is that I think it is more important to be obviously, unambiguously, totally hosed, b0rked, broken, rather than be quietly broken and appear perfectly normal. This is simply from my own experience trying to troubleshoot problems. If you version the vendor dirs the following scenario will play out. People will upgrade perl. No sigfaults, yay! Then they will wonder why perl says their modules are not installed, when pacman says that, yes indeed they are. Which modules? They don't quite know. Heck, they might not even notice until a week after they upgrade. In the end the result will be the same, they will still need to reinstall and/or rebuild modules, but it will be less obvious what the problem is. core_perl has no reason to versioned as far as I understand it. There can be only one! But yes, please... for the love of all that is holy, version the site_perl directory. -- -Justin
On 11.06.2014 09:47, Justin Davis wrote:
If you version the vendor dirs the following scenario will play out. People will upgrade perl. No sigfaults, yay! Then they will wonder why perl says their modules are not installed, when pacman says that, yes indeed they are. Which modules? They don't quite know. Heck, they might not even notice until a week after they upgrade. In the end the result will be the same, they will still need to reinstall and/or rebuild modules, but it will be less obvious what the problem is.
I'm not sure about that one. If modules are in a versioned dir it's way easier to run find on that dir and get a list of stuff that is clearly broken than it is right now. My find-broken-perl-packages.sh script tries to find them now, but that generates quite a few false positives because some modules just don't support direct loading (perl -MFoo::Bar -e1). Because of that I don't link it directly in the news post, but that obviously won't stop people from following a longer link chain anyway and then not being able to understand the output. I believe that would be easier if we version the dir. People sometimes upgrade partially and then complain (yes happened with 5.20), sometimes packages will be rebuilt against the wrong perl even if the same packager builds all his other pkgs against the right one (yes happened with 5.20) and also don't forget that cpanplus-dist-arch installs to vendor_perl so user-built stuff is also there. Telling people to check if the dir doesn't exist and otherwise run `find .. -exec pacman -Qqo {} + | sort -u` seems way easier than my current attempt. I agree it might be less obvious if you don't know we do that though, but I'll post news announcements with the command in there.
core_perl has no reason to versioned as far as I understand it. There can be only one! But yes, please... for the love of all that is holy, version the site_perl directory.
Ack.
participants (2)
-
Florian Pritz
-
Gaetan Bisson