On Thu, Aug 06, 2020 at 03:57:29AM +0800, Xi Ruoyao via lfs-dev wrote: > On 2020-08-05 19:53 +0100, Ken Moffat via lfs-dev wrote: > > (I've changed the subject and cut down some of hte obsolete detail) > > > > On Wed, Aug 05, 2020 at 04:22:49AM +0100, Ken Moffat via lfs-dev wrote: [...] > > > > False-ish alarm : the "missing" modules were installed in the > > initial (chapter 7) build, but they are in > > /usr/share/perl5/site_perl NOT /usr/lib/perl5/5.32/core_perl. > > > > The items in /usr/lib/perl5/5.32/core_perl were either installed by > > chapter 7 perl, as someone mentioned the other day, or (a few) were > > installed in chapter 8 perl. But all the items in /usr/share are > > from chapter 7 and ;acking the 5.32 version. > > > > At best, the location of the modules looks messy and I'm not happy > > that they are in unversioned directories. > > > > These are from the privlib. > > > > The first useful match for privlib which I found was a bug from a > > module developer (5.30 was doing somethign different from 5.26) > > where the output from cpan mentioned privlib: > > Dprivlib=/usr/local/cpanel/3rdparty/perl/530/lib/perl5/5.30.0 > > > > https://www.nntp.perl.org/group/perl.perl5.porters/2019/10/msg256381.html > > > > (Just pasting the link in case it is of any interest later) > > > > I think that > > > > https://stackoverflow.com/questions/54470275/what-is-the-difference-between-the-core-vendor-and-site-locations-in-perl > > > > provides detailed explanations, and that from the UPDATE there we > > should at least be using a version in the privlib i.e. > > /usr/share/perl5/5.32/core_perl. > > > > But until now we have managed without putting pure perl core modules > > in /usr/share (although ISTR that when we used separate modules > > related to git - perhaps Errno.pm - something did go into > > /usr/share. > > > > We did not used to have -Dprivlib, I guess that dropping that would > > stop core modules being placed in /usr/share. > > > > This leaves the items in /usr/lib/perl5/core_perl which were NOT > > updated in chapter 8. Looking at the times in ls -lR these are > > either pure perl modules (*.pm), headers (in CORE) or else > > directories. I'm happy that those have not been changed between > > chapter 7 and chapter 8. > > > > I'll start a build WITHOUT Dprivlib later. > > Is there any rationale to change the default Perl module directory, besides to > remove the Perl patch level from path? >
Som of the modules (.so libs) are in archlib, i.e. /usr/lib/perl5/5.32/core_perl > I suggest three alternatives: > > (1) -Dprivlib=/usr/share/perl5/5.32/core_perl > > It's like the status quo, but versioned. > I am hopeful that not specifying privlib will do that. If not, I will go with that. > (2) -Dprivlib=/usr/lib/perl5/5.32 > > It's almost the default, but patch level (".0") removed. -Darchlib will also > need to be adjusted. > I don't understand how you would change archlib ? At the moment it is /usr/lib/perl5/5.32/core_perl unless you mean to remove core_perl which was one of the features of Thomas's original proposal for the new layout : http://lists.linuxfromscratch.org/pipermail/lfs-dev/2020-June/073877.html The possibility that anything other than vendor modules (i.e. from third parties) would end up in /usr/share was not apparent. > (3) -Dprivlib=/usr/lib/perl5/5.32/core_perl > > It matches the current -Darchlib. > Another possibility. > And, -Dvendorlib should also be adjusted in the same manner. I suppose that setting vendorlib the same as vendorarch, i.e. /usr/lib/perl5/5.32/vendor_perl would make sense, but I don't have anything (third-party?) that installs in vendor_lib. Thanks for making me think about this a little more, even though my brain is now on the edge of meltdown ;-) ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page