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

Reply via email to