On Sun, 20 Feb 2022 at 12:55, Marco Fioretti <mfioretti@nexaima.net> wrote:
On Sun, Feb 20, 2022 at 16:05, Fulko Hew <fulko.hew@gmail.com> wrote:

And yes, I was (and always have) installed additional modules
via CPAN where Fedora doesn't have those modules.  (Trouble is that
even when Fedora can deliver one of those packages, they aren't
named the same and so it's hard to find what package to install.)

And then... What can you do when Fedora doesn't have it packaged?
Ignore CPAN.  I think not.  My gut feeling today is.  Why doesn't
Fedora distribute stuff that doesn't break CPAN?


(hoping this can raise wider awareness of the GENERAL problem with packages and packaging on Linux)

From everything you wrote, the problem may be more like "why does CPAN exist, complicating things in this way?"

For me it definitely is. To see why, just remember that CPAN is just one of tens of mutually unaware packaging systems that together make the whole concepts of distribution and repositories moot

Distributions, repositories and packaging formats like .deb or .rpm, and all their management tools, where invented exactly to save users the nightmare to deal with many different packaging systems, one per language. I used CPAN a lot in the 90s. then it, and all its equivalents became more and more of a burden, making the very concept of distros less and less meaningful, and useful, every year. Now, I sometimes think that CPAN, encouraging Ruby, Python, Java etc... to do the same, may have done more harm than good.

Many of these have low barriers for someone who wants to create a package.   Some packages 
may only be useful for a few users, and those users may all be using different platforms.   Some
very small fraction of those packages may go on to become widely used.   Open source makes it
easy for people to innovate, and we need to encourage experimentation, but we can't have 
experiments in linux distros.

In my field, NASA provides a large "mission critical" application which includes a private tree of
third-party libraries.   The same libraries are available from linux distros, but many have optional
configurations which differ across linux distros, so bundling the libraries is a big step towards
ensuring everyone gets a working configuration.   I think other large commercial packages
(Matlab, IDL) also bundle third-party libraries.


Everything else I could say on this topic is already here:



CPAN, CTAN, CRAN etc. exist because they support multiple OS's.  I suspect the great majority of
package installs are on Windows.   In some cases, linux distros repackage an entire CXAN in some
optional repository.  Many of these conversions can be done automatically, but there are always exceptions.

Diversity can be a curse or a strength.   There has been progress but also failures in efforts to deal with
linux package diversity.  The alien program converts between different distro package systems, but
does nothing to resolve dependencies.

Virtualization methods can provide the environment needed by packages from other distros, but
alien's conversions    Many people rely on conda to provide packages not available from their linux
distribution, or to provide the same packages across several distros or distro versions.

Packages are messy and likely always will be.  There is lots of room for improvements to
make it easier to unravel conflicts, or even warn of potential conflicts.   There has been work on
managing conflicts in Python: Managing Application Dependencies — Python Packaging User Guide.
For python, it is becoming common to have a separate python tree managed with conda/mamba for 
user applications and leave the system's python to the distro package manager.  

--
George N. White III