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
