Re: [lfs-dev] Perl privlib is putting core modules in /usr/share
On Thu, Aug 06, 2020 at 03:48:45AM +0100, Ken Moffat via lfs-dev wrote: > On Wed, Aug 05, 2020 at 10:03:52PM +0100, Ken Moffat via lfs-dev wrote: > > But by changing sitelib to > -Dsitearch=/usr/lib/perl5/5.32/site_perl > I have ended up with plain perl modules in /usr/lib/prel5/5.32.0 > such as my old friend Test/More.pm. > Wrong on two counts. First, sitelib not sitearch. Irrelevant to the main problem and it probably did the job. The main problem was that dropping '-Dprivlib=/usr/share/perl5/core_perl' caused perl to use its default. From Config.pm when doing that : privlibexp => '/usr/lib/perl5/5.32.0', As I've just replied to xry111, using /usr/share for sitelib is not at all like the defaults. ĸ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
Re: [lfs-dev] Perl privlib is putting core modules in /usr/share
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\
>
Re: [lfs-dev] Perl privlib is putting core modules in /usr/share
On Wed, Aug 05, 2020 at 10:03:52PM +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: > > > > > > 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. > I completed the chapter 7 build of perl, all the (plain) modules now in /usr/lib/perl5/5.32/core_perl/ and /usr/lib/perl5/site_perl was created. It also created /usr/share/perl5 which will be needed if anything ever uses vendor_perl. But it also created /usr/share/perl5/site_perl (sitelib) - I missed that. And after another run to stop that directory getting created I sat down to look at exactly what I had. In the book, modules are variously in /usr/lib/perl5/5.32/core_perl (good, as expected) and in /usr/share/perl5/core_perl (messy). By not defining privlib, the modules from /usr/share moved to /usr/lib/perl5/5.32/core_perl. But by changing sitelib to -Dsitearch=/usr/lib/perl5/5.32/site_perl I have ended up with plain perl modules in /usr/lib/prel5/5.32.0 such as my old friend Test/More.pm. Note that I have NOT specified 5.32.0 in any of the defines. The diff from my script is: @@ -41,7 +41,7 @@ sh Configure -des \ -Dprefix=/usr\ -Dvendorprefix=/usr \ -Darchlib=/usr/lib/perl5/5.32/core_perl \ - -Dsitelib=/usr/share/perl5/site_perl \ + -Dsitelib=/usr/lib/perl5/5.32/site_perl \ -Dsitearch=/usr/lib/perl5/5.32/site_perl \ -Dvendorlib=/usr/share/perl5/vendor_perl \ So apparently there is some weird interaction. I guess I'll revert that, live with the creation of /usr/share/perl5/site_perl and try again. ĸ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
Re: [lfs-dev] Perl privlib is putting core modules in /usr/share
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
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
Re: [lfs-dev] perl install options
On Sat, Jun 20, 2020 at 03:49:07PM +0100, Ken Moffat via lfs-dev wrote: > On Sat, Jun 20, 2020 at 07:05:24AM -0700, Joel Bion via lfs-dev wrote: > > Upgrading Perl was the trigger for me building my own package dependency > > tracker utility. With tons of manual configuration, I am able to upgrade > > any subset of packages at one time. It tells me what I need to rebuild, in > > what order. Some packages trigger no or few rebuilds. Others, like OpenSSL, > > trigger a few dozen. Python 3 might trigger 100. Perl is crazy; it triggers > > 100s. > > > > Each package has a build script I’ve written. If I ever get around to it, > > I’ll make it generate a super-script that involves unpacking the tar files, > > so I can just automate the whole build. > > > > Sent from my iPhone > > > I won't complain about top-posting in the light of that last line! > > You must build a _lot_ more than I do: I've got several non-book > perl modules which I sometimes build, and there are a few modules in > the book which I never build, but in the perl directory of my > scripts I only have 150 modules. > I suppose it depends how you define a module, I was counting tarballs. Now that I've looked at the plain perl modules that are now in /usr/share I found over 500 '*.pm' in site_perl. ĸ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
Re: [lfs-dev] Perl privlib is putting core modules in /usr/share
On Wed, Aug 05, 2020 at 10:03:52PM +0100, Ken Moffat via lfs-dev wrote: > > The possibility that anything other than vendor modules (i.e. from > third parties) would end up in /usr/share was not apparent. > In fact, Git.pm IS installed in /usr/share/perl5/ rather than e.g. /usr/share/perl5/site_perl/ or /usr/lib/perl5/5.32/site_perl. Hmm. with perl there is _always_ another way for someone to do something. Now that I'm looking at /usr/share/perl5/ I see that as well as our core_perl and site_perl (again, lots of the extra mdules I've installed are in that site_perl) there are: FromCPAN (Error.pm and Mail/Address.om), Git/*/* and Git.pm all of which come from it. None of those match our current overrides and I don't see anything like that in Config.pm nor in Config_heavy.pl. ĸ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
Re: [lfs-dev] Perl privlib is putting core modules in /usr/share
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
Re: [lfs-dev] Perl privlib is putting core modules in /usr/share
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
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
[lfs-dev] Perl privlib is putting core modules in /usr/share
(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. ĸ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
Re: [lfs-dev] grub with uefi for LFS 10?
On 8/5/20 2:25 AM, Xi Ruoyao via lfs-dev wrote: On 2020-08-05 14:37 +0800, Kevin Buckley via lfs-dev wrote: On Mon, 3 Aug 2020 at 00:46, Xi Ruoyao via lfs-dev wrote: It's nearly impossible. If we do that we'll have to introduce at least five new packages: dosfstools, popt, pciutils, efivar, and efibootmgr. Pciutils is recommended to be installed along with "which" (it's a package's name), and one of wget/curl/lynx to make update-pciids script usable. And, to make grub menu "showing normal" we'll need freetype. Freetype has a circular dependency with harfbuzz. Harfbuzz requires glib, graphite, and ICU to be fully functional. Worth pointing out, as the hint does, that you can install Freetype without the harfbuzz, so as to get enough to install an enhanced Grub, and then go back and install a Freetype+harfbuzz later. That's my approach, and OK for a hint. Another way: provide a binary unicode.pf2 file on Anduin, and skip freetype. It's just a font and it's not a problem not to build a font "from scratch". Similarly, the lack of an update-pciids script may not be a major problem as, when building the UEFI-aware Grub for the first time, you can download what that script would fetch, using the host system, and just put the payload into place on the LFS system. The problem is we have to defer the activation of update-usbids.timer (for systemd) or cron job (for sysv) after wget/curl/lynx is installed. Then where should we put the instruction? Not a technical problem but a book structure issue. It's probably way too far beyond LFS to have it in the LFS Book, but the basic capabilities are not as hard to add as one might come to think, just by following all of the BLFS Book's dependencies to the end of each chain. I think it might be better to put EFI grub and its dependencies into BLFS. There is BLFS #5379 (opened 6 years ago). If Bruce agrees I'll change the milestone to 10.1 (10.0 will be too hurry) and do it. And, William Harrington suggested that LFS should support some non-x86 architectures, which would require different bootloaders. They can be put into a new BLFS chapter "alternative bootloaders", along with EFI grub. If you can maintain it on an ongoing basis, I'm OK with adding a section on bootloaders in 10.1. I went ahead and added a 10.1 milestone to BLFS. When you are ready, we can discuss where it should go in the book. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] grub with uefi for LFS 10?
On 2020-08-05 14:37 +0800, Kevin Buckley via lfs-dev wrote: > On Mon, 3 Aug 2020 at 00:46, Xi Ruoyao via lfs-dev > wrote: > > It's nearly impossible. If we do that we'll have to introduce at least five > > new > > packages: dosfstools, popt, pciutils, efivar, and efibootmgr. Pciutils is > > recommended to be installed along with "which" (it's a package's name), and > > one > > of wget/curl/lynx to make update-pciids script usable. And, to make grub > > menu > > "showing normal" we'll need freetype. Freetype has a circular dependency > > with > > harfbuzz. Harfbuzz requires glib, graphite, and ICU to be fully functional. > > > > Worth pointing out, as the hint does, that you can install Freetype > without the harfbuzz, so as to get enough to install an enhanced > Grub, and then go back and install a Freetype+harfbuzz later. That's my approach, and OK for a hint. Another way: provide a binary unicode.pf2 file on Anduin, and skip freetype. It's just a font and it's not a problem not to build a font "from scratch". > Similarly, the lack of an update-pciids script may not be a major > problem as, when building the UEFI-aware Grub for the first time, > you can download what that script would fetch, using the host > system, and just put the payload into place on the LFS system. The problem is we have to defer the activation of update-usbids.timer (for systemd) or cron job (for sysv) after wget/curl/lynx is installed. Then where should we put the instruction? Not a technical problem but a book structure issue. > It's probably way too far beyond LFS to have it in the LFS Book, > but the basic capabilities are not as hard to add as one might > come to think, just by following all of the BLFS Book's dependencies > to the end of each chain. I think it might be better to put EFI grub and its dependencies into BLFS. There is BLFS #5379 (opened 6 years ago). If Bruce agrees I'll change the milestone to 10.1 (10.0 will be too hurry) and do it. And, William Harrington suggested that LFS should support some non-x86 architectures, which would require different bootloaders. They can be put into a new BLFS chapter "alternative bootloaders", along with EFI grub. -- Xi Ruoyao 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
Re: [lfs-dev] grub with uefi for LFS 10?
On 2020-08-05 14:26 +0800, Kevin Buckley via lfs-dev wrote: > On Sun, 2 Aug 2020 at 04:32, Timothy Russo via lfs-dev > wrote: > > With efi being more the standard now, I'd like to ask if we could default > > grub to supporting uefi instead of having to use the uefi hint. > > > > Or at last maybe formalize it and make it an option, where you can pick > > bios/mbr or uefi option. > > > > As the last person to update that hint (and, yes, it's in need of more > updating > for newer package versions!), then you must have seen that there are extra > packages, beyond those in the LFS core, that are needed to "enhance" Grub. > > Note also, that as you are probably building LFS on a system that may have > a UEFI-aware bootloader, you don't necessarily need a bootloader provided > by LFS. > > Maybe a UEFI-aware Grub could be part of BLFS though? [Cross post to blfs-dev] I personally agree. Let's hear Bruce's opinion. If he agree I'll do it for BLFS 10.1, and reference it in LFS 10.1. 10.0 is too hurry, I think. For 10.0 I'll update the hint again. -- Xi Ruoyao 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
Re: [lfs-dev] grub with uefi for LFS 10?
On Sun, 2 Aug 2020 at 04:32, Timothy Russo via lfs-dev wrote: > > With efi being more the standard now, I'd like to ask if we could default > grub to supporting uefi instead of having to use the uefi hint. > > Or at last maybe formalize it and make it an option, where you can pick > bios/mbr or uefi option. > As the last person to update that hint (and, yes, it's in need of more updating for newer package versions!), then you must have seen that there are extra packages, beyond those in the LFS core, that are needed to "enhance" Grub. Note also, that as you are probably building LFS on a system that may have a UEFI-aware bootloader, you don't necessarily need a bootloader provided by LFS. Maybe a UEFI-aware Grub could be part of BLFS though? As the hint points out, most of the extra packages are already in BLFS. Kevin -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
