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 > On Jun 20, 2020, at 6:54 AM, Ken Moffat via lfs-dev > <lfs-dev@lists.linuxfromscratch.org> wrote: > > 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 >> >> /usr >> /lib >> /perl5 >> /5.30.2 >> /... >> /site_perl >> >> 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 >> >> /usr >> /lib >> /perl5 >> /5.30.2 >> /... >> /5.30.3 >> /... >> /site_perl >> >> 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. > > 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 ? > >> 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. >> >> 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). > > ĸ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 -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page