#4710: Tidy the new-style perl so that all modules are in /usr/lib
--------------------+-----------------------
Reporter: ken@… | Owner: renodr
Type: task | Status: assigned
Priority: normal | Milestone: 10.0
Component: Book | Version: SVN
Severity: normal | Resolution:
Keywords: |
--------------------+-----------------------
Comment (by thomas):
Just my 2 ct here:
Its true, i assumed that perl5 will continue. The initial basic idea of
tweaking the paths was to avoid constant rebuilds of modules when even
only the patch level of Perl has changed. And i also assumed that a patch
level increase will not introduce changes which renders those modules
unusable.
So having the 5.32 in the pathes will make it possible to simply upgrade
from perl-5.32.x to perl-5.32.y without rebuilding. If minor or even major
version changes (5.32.x --> 5.34.x), rebuild will be required - but that
is exactly same as what we had before even only the patch level changes.
But until a min/maj increase occurs, we need not to rebuild.
Moving the PMs to /usr/share: To be honest, i've no real means in that.
As said before, the only reason to change the pathes was to keep modules
alive when an increase of patch-version of perl occurs.
Now, the discussion about change has extended a bit into a discussion
where PMs should be stored in general. I also see scriptfiles more in
platform independent category as other objects but is it possible to cut
the line that exact? I tend to leave it as it was even though the tweak of
the install pathes introduced the usage of /usr/share. I admit that it has
been simply taken from Archs instructions. Maybe this should have been
taken more under investigation about the effect of using it that way.
If using /usr/share, we have to have a look to TCL as well since this
package also installs modules in /usr/lib (for instance
/usr/lib/tcl8/8.6/http-2.9.1.tm). I think with tcl the 'problem' is the
same but it hasn't come up so far as it looks like we hardly use tcl or
tcl is hardly used by other pkgs which installs/require additional
modules.
That said, i think xry111's proposal looks quite nice and keeps stuff
together were it always has been. If i see it right, result would be quite
same as in python where interpreter as well as modules are under /usr/lib.
--
Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/4710#comment:7>
LFS Trac <http://wiki.linuxfromscratch.org/lfs/>
Linux From Scratch: Your Distro, Your Rules.
--
http://lists.linuxfromscratch.org/listinfo/lfs-book
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
