Tidy the new-style perl so that all modules are in /usr/lib

[ken@…]

Before we moved to the new-style of perl install, all modules from perl itself, and almost all modules from BLFS (the exception is Git) were in /usr/lib/perl5.

With what is currently in the book, a lot of core and other modules are in /usr/share/perl5{core_perl,site_perl}

Summarising, -Dprivlib is needed to ensre that the default is not used for the modules that moved to /usr/share, but the default for that is /usr/lib/perl5/5.32.0 so we ought to change it to match our other changes.

We also need to similarly change sitelib.

xry111 suggested the following, it works nicely:

sh Configure -des                                         \
             -Dprefix=/usr                                \
             -Dvendorprefix=/usr                          \
             -Dprivlib=/usr/lib/perl5/5.32/core_perl      \
             -Darchlib=/usr/lib/perl5/5.32/core_perl      \
             -Dsitelib=/usr/lib/perl5/5.32/site_perl      \
             -Dsitearch=/usr/lib/perl5/5.32/site_perl     \
             -Dvendorlib=/usr/lib/perl5/5.32/vendor_perl  \
             -Dvendorarch=/usr/lib/perl5/5.32/vendor_perl \
             -Dman1dir=/usr/share/man/man1                \
             -Dman3dir=/usr/share/man/man3                \
             -Dpager="/usr/bin/less -isR"                 \
             -Duseshrplib                                 \
             -Dusethreads

I have also built several modules (in chroot), git with the sed I will be proposing for BLFS, and used cpan to install a module. All the modules are in either /usr/lib/perl5/5.32/core_perl or /usr/lib/perl5/5.32/site_perl.

I think we should make this change ASAP, but I'm not sure that everyone relevant has read my sometimes-confused threads on the list.

[Bruce Dubbs]

I've been following the posts on the mailing lists, but was waiting for things to get sorted out.

It is my understanding that /usr/lib is for architecture dependent files and /usr/share for architecture independent files. Aren't the .pm files architecture independent?

Also, I'm not sure about forcing 5.32 in the directory paths. Does that mean that all modules need to be rebuilt when the next perl minor version, I assume 5.33, is released?

[ken@…]

Replying to bdubbs:

I've been following the posts on the mailing lists, but was waiting for things to get sorted out.

It is my understanding that /usr/lib is for architecture dependent files and /usr/share for architecture independent files. Aren't the .pm files architecture independent?

Also, I'm not sure about forcing 5.32 in the directory paths. Does that mean that all modules need to be rebuilt when the next perl minor version, I assume 5.33, is released?

The next versions are likely to be 5.32 point releases, unless we are brave enough (or insane enough) to use perl-7 in about a year's time. If 5.33 happens, then it will be a development version, save as 5.31.

After perl-7, perl-8 will not be compatible with perl 5.

And I will stress that Thomas's proposal was for long-term support on the apparent assumption that perl5 would continue.

To suggest that moving so many modules to /usr/share which used to be in /usr/lib is expected behaviour is a surprise to me, and I would appreciate Thomas's comments. Before the change, /usr/share/perl5 was all-but empty. Now it contains a lot:

ken@deluxe ~ $ls /usr/share/perl5/core_perl/
AnyDBM_File.pm  charnames.pm    English.pm       IO                Perl            Test.pm
App             Class           Env.pm           IPC               perl5db.pl      Text
Archive         Compress        experimental.pm  JSON              perlfaq.pm      Thread
Attribute       Config          Exporter         less.pm           PerlIO          Thread.pm
autodie         constant.pm     Exporter.pm      Locale            PerlIO.pm       Tie
autodie.pm      CORE.pod        ExtUtils         locale.pm         pod             Time
AutoLoader.pm   CPAN            Fatal.pm         Math              Pod             Unicode
AutoSplit.pm    CPAN.pm         feature.pm       Memoize           Safe.pm         unicore
autouse.pm      DBM_Filter      fields.pm        Memoize.pm        Search          UNIVERSAL.pm
B               DBM_Filter.pm   File             meta_notation.pm  SelectSaver.pm  User
base.pm         DB.pm           FileCache.pm     Module            SelfLoader.pm   utf8.pm
Benchmark.pm    deprecate.pm    FileHandle.pm    Net               sigtrap.pm      vars.pm
bigint.pm       Devel           filetest.pm      NEXT.pm           sort.pm         version
bignum.pm       diagnostics.pm  Filter           ok.pm             strict.pm       version.pm
bigrat.pm       Digest          FindBin.pm       open.pm           subs.pm         version.pod
blib.pm         Digest.pm       Getopt           overload          Symbol.pm       vmsish.pm
bytes_heavy.pl  DirHandle.pm    HTTP             overloading.pm    TAP             warnings
bytes.pm        Dumpvalue.pm    I18N             overload.pm       Term            warnings.pm
Carp            dumpvar.pl      if.pm            Params            Test            XSLoader.pm
Carp.pm         Encode          integer.pm       parent.pm         Test2
_charnames.pm   encoding        Internals.pod    Parse             Test2.pm
ken@deluxe ~ $ls /usr/share/perl5/site_perl/
Alien         Encode  Importer.pm  Mojo            Path           SUPER.pm     Try
alienfile.pm  FFI     IO           Mojolicious     Scope          Term         URI
Archive       File    libwww       Mojolicious.pm  SGMLS          Test         URI.pm
Capture       HTML    LWP          Mojo.pm         sgmlspl-specs  Test2        WWW
Date          HTTP    LWP.pm       Net             SGMLS.pm       Time         XML
Devel         Image   Module       ojo.pm          Sub            TimeDate.pm
ken@deluxe ~ $

[Bruce Dubbs]

I was just stating my understanding, not making a change proposal. The idea of non-architecture dependent files in /usr/share goes back to the days where disks were small and expensive and /usr/share was on a remote system shared by all architectures.

Today that is not really needed when m.2 SSDs are starting to approach $100/terabyte.

[Douglas R. Reno]

Do I need to make these changes to Chapter 7 as well, or just Chapter 8?

[Pierre Labastie]

Replying to renodr:

Do I need to make these changes to Chapter 7 as well, or just Chapter 8?

In both: otherwise, the files installed in chapter 7 don't get overwritten in chapter 8...

[thomas]

Just my 2 ct here:

Its true, i assumed that perl5 will continue. The initial basic idea of tweaking the paths was to avoid constant rebuilds of modules when even only the patch level of Perl has changed. And i also assumed that a patch level increase will not introduce changes which renders those modules unusable.

So having the 5.32 in the pathes will make it possible to simply upgrade from perl-5.32.x to perl-5.32.y without rebuilding. If minor or even major version changes (5.32.x --> 5.34.x), rebuild will be required - but that is exactly same as what we had before even only the patch level changes. But until a min/maj increase occurs, we need not to rebuild.

Moving the PMs to /usr/share: To be honest, i've no real means in that. As said before, the only reason to change the pathes was to keep modules alive when an increase of patch-version of perl occurs. Now, the discussion about change has extended a bit into a discussion where PMs should be stored in general. I also see scriptfiles more in platform independent category as other objects but is it possible to cut the line that exact? I tend to leave it as it was even though the tweak of the install pathes introduced the usage of /usr/share. I admit that it has been simply taken from Archs instructions. Maybe this should have been taken more under investigation about the effect of using it that way.

If using /usr/share, we have to have a look to TCL as well since this package also installs modules in /usr/lib (for instance /usr/lib/tcl8/8.6/http-2.9.1.tm). I think with tcl the 'problem' is the same but it hasn't come up so far as it looks like we hardly use tcl or tcl is hardly used by other pkgs which installs/require additional modules.

That said, i think xry111's proposal looks quite nice and keeps stuff together were it always has been. If i see it right, result would be quite same as in python where interpreter as well as modules are under /usr/lib.

[ken@…]

Replying to renodr:

Do I need to make these changes to Chapter 7 as well, or just Chapter 8?

Now that there is agreement, I'm doing this.

[ken@…]

Replying to thomas:

Now, the discussion about change has extended a bit into a discussion where PMs should be stored in general. I also see scriptfiles more in platform independent category as other objects but is it possible to cut the line that exact? I tend to leave it as it was even though the tweak of the install pathes introduced the usage of /usr/share. I admit that it has been simply taken from Archs instructions. Maybe this should have been taken more under investigation about the effect of using it that way.

After looking at what happened when trying variations of privlib, I concluded that script files (*.pl) seem to be mixed in with various other things.

If using /usr/share, we have to have a look to TCL as well since this package also installs modules in /usr/lib (for instance /usr/lib/tcl8/8.6/http-2.9.1.tm). I think with tcl the 'problem' is the same but it hasn't come up so far as it looks like we hardly use tcl or tcl is hardly used by other pkgs which installs/require additional modules.

For tcl, the only extra module I have from BLFS is /usr/lib/tcl8/8.6/tdbc/sqlite3-1.1.1.tm. I notice that tcl also installed modules in /usr/lib/tcl8/8.4 and /usr/lib/tcl8/8.5.

[ken@…]

r12017