On Tuesday, November 19, 2019 9:20:29 AM MST Kevin Kofler wrote:
But the scripts do not need to care about the version of Perl you are
running, do they? It matters for compiled code, but why for Perl scripts?
Those can just run with the default version of Perl if they support it, or
with the shebang line changed to something like #!/usr/bin/perl5.30 if
that's what they require.
There are certain edge cases where the version really does matter for scripts,
but for most scripts you would be correct. I also agree with your solution for
scripts that actually do require a specific version, however.
The best way to deal with conflicts in PATH is to suffix the
binaries, not
to move them. But that is only needed when it makes a difference for the
end user which version they run. If the executable script "foo" does the
exact same thing when run under Perl 5.28 or 5.30, then you need only one
/usr/bin/foo set up to run against the distribution default Perl, the other
one is redundant (which is the nice thing about parallel installation: you
do not have to support running all the executables under a non-default
Perl, only those that actually need it).
While that would work well in the Perl context, there are cases where it
wouldn't work, for example there are several programs which hard-code paths
which we would need to come up with an alternative path for and patch.
I think that any model that has conflicts is not workable for the
Fedora
user base. Desktops and small servers are not normally containerized, so
being able to install different applications without conflict is a non-
negotiable requirement.
Agreed, in fact most workstations and servers with RHEL are not containerized
either. Before RHEL 8, which was essentially just released, nothing even
recommended containerizing RHEL.
--
John M. Harris, Jr.
Splentity