On Thu, Aug 06, 2020 at 10:31:52AM +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-08-05 22:03 +0100, Ken Moffat via lfs-dev wrote:
> > 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.
>
> It's not. The default is /usr/lib/perl5/5.32.0.
>
> > > (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.
>
> I prefer to put everything into /usr/lib/perl5, instead of using
> /usr/share/perl5. Like:
>
> 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
Thanks! After sending my previous post I realised I'd been looking
at the wrong log and got myself confused - the plain perl in
/usr/share started appearing in /usr/lib/perl5/5.32.0/ when the
privlib define was removed, so obviously the old-style location is
the default for that when perl is in /usr and it should NOT be in
/usr/share.
So, I had independently come up with everything you have and was
just about to try it.
ĸ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
