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
