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: > > O Wed, Aug 05, 2020 at 01:54:44AM +0100, Ken Moffat via lfs-dev wrote: > > > I'm looking at perl module dependencies, and I can see a reference > > > to Test::More in a test, although I'm not sure if that test actually > > > gets run. The reason I'm askng is that this used to be a core > > > module, but I cannot see it in my 5.32.0 builds, althought the man > > > page for Test::More.3 is still installed. > > > > > > Looking at https://perldoc.perl.org/Test/More.html suggests it is > > > still part of core perl. > > > > > > Does anyone have any knowledge of this, please ? > > > > > > ĸen > [...] > > It occurred to me that I could go to my backups and look at the > > files from the last old-style build I did. That was for 5.30.3, so > > I expect some slight variation. > > > > What I did in each of the core perl root directories was run > > find . -name '*.pm' | sort >somefile > > > > I'm attaching these (new-style-5.32.0 first), on the face of it I > > seem to have lost a phenomenal amount of modules. But so far all my > > perl module builds and tests have worked, so I hope I'm missing > > something obvious. > > > > 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? I suggest three alternatives: (1) -Dprivlib=/usr/share/perl5/5.32/core_perl It's like the status quo, but versioned. (2) -Dprivlib=/usr/lib/perl5/5.32 It's almost the default, but patch level (".0") removed. -Darchlib will also need to be adjusted. (3) -Dprivlib=/usr/lib/perl5/5.32/core_perl It matches the current -Darchlib. And, -Dvendorlib should also be adjusted in the same manner. -- Xi Ruoyao <xry...@mengyan1223.wang> School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page