![](https://seccdn.libravatar.org/avatar/fff0f38e92656c8a636916213eb952c4.jpg?s=120&d=mm&r=g)
Hi, On Wed, 26 Apr 2017, Jan Engelhardt wrote:
/usr/lib/perl5 is one of the big blobs with its own way of doing things. Many (but not all) of the files therein are not arch dependend or binary, and hence would actually have a better place under /usr/share. The binary files that are there are not shared libraries for the dynamic loader but dlopen modules, so that would speak for libexec.
It's not that easy. perl also exists as a dynamic loader library (libperl.so) that could exist in multiple bitnesses, which means all the Perl modules (well,mthe XS things) cannot be libexec aka single bitness.
That should be taken care of by the arch-dependend mechanism that perl already has: % echo $PERL5LIB /suse/matz/perl5/lib/perl5:/suse/matz/perl5/lib/perl5:/suse/matz/perl5/lib/perl5 % perl -V ... /suse/matz/perl5/lib/perl5/x86_64-linux-thread-multi /suse/matz/perl5/lib/perl5 ... /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.2 So, libperl.so goes into lib{,64} the modules and header wrappers (if arch dependend) into the libexec/perl5/$triplet directories. python could probably be made to do similar things. Now, having said this, in might very well be that perl turns out to be in the "ah, crap, too much work, ignore it" category and remains an exception, even if we otherwise would follow a changed policy of having libexec. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org