Am Samstag, den 20.06.2020, 14:53 +0100 schrieb Ken Moffat via lfs-
dev:
> On Sat, Jun 20, 2020 at 02:42:03PM +0200, Thomas Trepl via lfs-dev wrote:
> > Hi all,
> >
> > this is about hte configuration options of perl.
> >
> > Problem:
> > whenever perl is upgraded to a newer version (for example 5.30.2 to
> > 5.30.3), all perl modules needs to be reinstalled as the current
> > configuration of perl forces a directory structure like
> >
<snip>
> >
> > All modules are installed under /usr/lib/perl5/5.30.2 . Now, when
> > installing a newer patch-version by overwriting the existing one, the
> > structure looks like
> >
<snip>
> >
> > The 5.30.2-directory (which includes the modules) is more or less
> > garbage as the new perl will use 5.30.3. Therefore, any installed
> > module must be reinstalled to appear in the 5.30.3 structure.
> >
> > This all is not really a problem as long as the system is completely
> > built from scratch and all modules are installed freshly. For those
> > who uses some kind of pkgmnr or upgrade the system package by package
> > it might be a problem when perl is about to upgrade.
> >
>
> Yes, for my own systems I have had to rebuild all the modules if
> upgrading perl.
>
> > Suggestion:
> > The following is under the assumption that patch-versions of perl are
> > compatible to each other. To solve the upgrade issue described above,
> > add a few new options to the perl install command in the LFS book:
> >
> > sh Configure -des \
> > -Dprefix=/usr \
> > -
> > Dvendorprefix=/usr \
> > * -Dprivlib=/usr/share/perl5/core_perl
> > \
> > * -Darchlib=/usr/lib/perl5/&perl-version-min;/core_perl \
> > * -
> > Dsitelib=/usr/share/perl5/site_perl \
> > * -
> > Dsitearch=/usr/lib/perl5/&perl-version-min;/site_perl \
> > * -
> > Dvendorlib=/usr/share/perl5/vendor_perl \
> > * -
> > Dvendorarch=/usr/lib/perl5/&perl-version-min;/vendor_perl \
> > -
> > Dman1dir=/usr/share/man/man1 \
> > -Dman3dir=/usr/share/man/man3 \
> > -
> > Dpager="/usr/bin/less -isR" \
> > -Duseshrplib \
> > -
> > Dusethreads
> >
> > assuming that we have in packages.ent:
> >
> > <!ENTITY perl-version-major "5">
> > <!ENTITY perl-version-minor "30">
> > <!ENTITY perl-version-patch "3">
> > <!ENTITY perl-version-min "&perl-version-major;.&perl-version-minor;">
> > <!ENTITY perl-version "&perl-version-major;.&perl-version-
> > minor;.&perl-version-patch;">
> >
> > This will produce a directory structure:
> >
> > /usr
> > /lib
> > /perl5
> > /5.30
> > /core_perl
> > /...
> > /site_perl
> > /...
> >
> > where modules are installed under /usr/lib/perl5/5.30/site_perl/ . In
> > this case, overwriting the installed perl with a newer one has no
> > effect on the installed modules unless minor or even major version of
> > perl >
>
> Sounds nice. But just to be clear - under site_perl I have a
> versioned directory (e.g. 5.30.2 for your current example). I
> assume, or hope, that will either be 5.30 or completely omitted.
This versioned subdir will be omitted completely. Files from
XML::Parser are installed as
usr/lib/perl5/5.30/site_perl/auto
usr/lib/perl5/5.30/site_perl/auto/XML
usr/lib/perl5/5.30/site_perl/auto/XML/Parser
usr/lib/perl5/5.30/site_perl/auto/XML/Parser/.packlist
usr/lib/perl5/5.30/site_perl/auto/XML/Parser/Expat
usr/lib/perl5/5.30/site_perl/auto/XML/Parser/Expat/Expat.so
usr/lib/perl5/5.30/site_perl/XML
usr/lib/perl5/5.30/site_perl/XML/Parser
usr/lib/perl5/5.30/site_perl/XML/Parser/Encodings
usr/lib/perl5/5.30/site_perl/XML/Parser/Style
usr/lib/perl5/5.30/core_perl
usr/lib/perl5/5.30/core_perl/perllocal.pod
net-ssleay installs as
...
usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/randomize.al
usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/do_httpx2.al
usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/put_https3.al
usr/lib/perl5/5.30/site_perl/auto/Net/SSLeay/do_https3.al
usr/lib/perl5/5.30/site_perl/Net
usr/lib/perl5/5.30/site_perl/Net/SSLeay.pod
usr/lib/perl5/5.30/site_perl/Net/SSLeay
usr/lib/perl5/5.30/site_perl/Net/SSLeay/Handle.pm
usr/lib/perl5/5.30/site_perl/Net/SSLeay.pm
...
>
> i.e. /usr/lib/perl5/5.30/site_perl/5.30/ or
> /usr/lib/perl5/5.30/site_perl/ for the directory where 'top level'
> modules SGMLS.pm and URI.pm live ?
URI: usr/share/perl5/site_perl/URI.pm
this pkg seems to use the "sitelib" instead of "sitearch"
configuration target. Any info why/when this target is used?
> > A note to "make install" might be required as perl refuses to
> > overwrite an installation in case of an version mismatch (which makes
> > sense in case of incompatible version, maybe when minor or major
> > version changes). To overcome this, a
> > mv /usr/bin/perl{,.old}
> > can be executed before doing the install.
seems not to be true. Overwriting went fine without any hickups.
I just tested:
Installed perl-5.30.2, installed XML::Parser and net-ssleay. "cpan -l"
shows both:
perl --version:
This is perl 5, version 30, subversion 2 (v5.30.2) built for x86_64-
linux-thread-multi
cpan -l:
XML::Parser 2.46
Net::SSLeay 1.88
...
Than, followed books instruction (with adjusted configure options) to
build perl-5.30.3. "make install" went fine.
perl --version:
This is perl 5, version 30, subversion 3 (v5.30.3) built for x86_64-
linux-thread-multi
cpan -l:
XML::Parser 2.46
Net::SSLeay 1.88
...
I also downgraded back to 5.30.2, Modules still usable (running "cpan
-l" as well as a small test script which does xml parsing).
> > As far as i have seen, there is no change required for BLFS except one
> > textual adjustment in the "Perl Modules" page.
> >
> > All comments, suggestions, tomatos and eggs are welcome!
> > Is there something i have completely overseen?
> >
>
> For plain perl modules in site_perl this sounds like a no-brainer.
> A quick look at .so files installed under x86_64-linux-thread-multi
> suggests that the site_perl files (e.g. from ImageMagick) do not
> link to perl libs, so should be ok, and the many core .so files seem
> (from a brief look at one or two) to only link to libc, vdso and
> ld-linux - in any case, the core files will be overwritten by the
> upgrade of perl.
>
> If a module is dropped from core perl, I suppose that will leave the
> old core module in place.
>
> Overall, I think it might be worth trying (I've had so much pain
> from perl over the years that I don't really believe there is such a
> thing as a free lunch, and my first semi-supported version with this
> would be LFS-10.0 so I won't actually find out for some months if
> the approach lives up to expectations).
It would be super cool if you, Ken (and of course others too!), could
test that too.
--
Thomas
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
