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
