On Sun, 20 Feb 2022 at 12:55, Marco Fioretti <mfiore...@nexaima.net> wrote:
> On Sun, Feb 20, 2022 at 16:05, Fulko Hew <fulko....@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: > > https://stop.zona-m.net/2022/01/the-sorry-sorry-state-of-linux-packaging/ > 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 <https://packaging.python.org/en/latest/tutorials/managing-dependencies/>. 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
_______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
