On Mon, Jun 22, 2020 at 10:13:19PM +0200, Thomas Trepl wrote: > 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? >
I had no idea, but from https://stackoverflow.com/questions/54470275/what-is-the-difference-between-the-core-vendor-and-site-locations-in-perl it might be a difference between 'pure perl' and binary, i.e. sitelib is for pure perl. > > > > 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 > It's on my ToDo list (or maybe my tuit list, as in waiting for a round tuit i.e. eventually I'll get around to it). First, I've got non-computer things to get started, but also forthcoming upgrades for mutt and (next week) firefox - and a bigger delay is that although I thought I'd matched my LFS scripts to the cross2 book, when I was exploring my gcc test failures I discovered that I still had SED=sed in the commands. I used to have separate git branches for my master (svn) and cross* LFS scripts, with BLFS only updated in master, and then I copied BLFS and, I thought, all later changes, into the branch and then swapped branches. I now suspect that I maybe missed one or two commits, or else didn't pay enough attention when checking against the book. But whichever, I'll be using 5.32 for new builds and I doubt 5.32.1 will appear before LFS-10.0 unless one of the monks has really screwed up somewhere. ĸen -- He died at the console, of hunger and thirst. Next day he was buried, face-down, nine-edge first. - the perfect programmer -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
