I'm not sure when it started, but on everything more complicated than print 'Hello World' my perl is failing. For example:
$ perl -e 'use DateTime;' Attempt to reload List/Util.pm aborted. Compilation failed in require at /usr/share/perl5/vendor_perl/namespace/ autoclean.pm line 11. BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/namespace/ autoclean.pm line 11. Compilation failed in require at /usr/lib64/perl5/vendor_perl/DateTime.pm line 9. BEGIN failed--compilation aborted at /usr/lib64/perl5/vendor_perl/DateTime.pm line 9. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1.
or
$ cpan Attempt to reload Scalar/Util.pm aborted. Compilation failed in require at /usr/share/perl5/Safe.pm line 4. BEGIN failed--compilation aborted at /usr/share/perl5/Safe.pm line 4. Compilation failed in require at /usr/share/perl5/vendor_perl/CPAN.pm line 57. BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/CPAN.pm line 57. Compilation failed in require at /usr/share/perl5/vendor_perl/App/Cpan.pm line 290. BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/App/Cpan.pm line 290. Compilation failed in require at /usr/bin/cpan line 7. BEGIN failed--compilation aborted at /usr/bin/cpan line 7.
Since I last saw it working, all I can do is remember upgrading to F35, or the daily updates.
Can anyone suggest where to start? For example... Why is it trying to reload Scalar::Util?
Hi Fulko,
I'm not sure when it started, but on everything more complicated than print 'Hello World' my perl is failing. For example:
$ perl -e 'use DateTime;' Attempt to reload List/Util.pm aborted. Compilation failed in require at /usr/share/perl5/vendor_perl/namespace/autoclean.pm line 11. BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/namespace/autoclean.pm line 11. Compilation failed in require at /usr/lib64/perl5/vendor_perl/DateTime.pm line 9. BEGIN failed--compilation aborted at /usr/lib64/perl5/vendor_perl/DateTime.pm line 9. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1.
or
$ cpan Attempt to reload Scalar/Util.pm aborted. Compilation failed in require at /usr/share/perl5/Safe.pm line 4. BEGIN failed--compilation aborted at /usr/share/perl5/Safe.pm line 4. Compilation failed in require at /usr/share/perl5/vendor_perl/CPAN.pm line 57. BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/CPAN.pm line 57. Compilation failed in require at /usr/share/perl5/vendor_perl/App/Cpan.pm line 290. BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/App/Cpan.pm line 290. Compilation failed in require at /usr/bin/cpan line 7. BEGIN failed--compilation aborted at /usr/bin/cpan line 7.
Since I last saw it working, all I can do is remember upgrading to F35, or the daily updates.
Can anyone suggest where to start? For example... Why is it trying to reload Scalar::Util?
Try to identify which cpan you're using (the one from Fedora repos installed via dnf or the one from CPAN) and try to reinstall (or remove...) that one.
Looks like you've mixed Perl modules installed from CPAN with others installed from Fedora. That's not always working.
Maybe you get more clues trying the debugger as well,
$ perl -d -e 'use DateTime;'
Best regards,
Iosif Fettich
On Sat, Feb 19, 2022 21:02:55 PM +0200, Iosif Fettich wrote:
Hi Fulko,
I'm not sure when it started, but on everything more complicated than print 'Hello World' my perl is failing. ...
Try to identify which cpan you're using (the one from Fedora repos installed via dnf or the one from CPAN) and try to reinstall (or remove...) that one.
Looks like you've mixed Perl modules installed from CPAN with others installed from Fedora. That's not always working.
This really seems just another textbook case of this general madness:
https://stop.zona-m.net/2022/01/the-sorry-sorry-state-of-linux-packaging/
no solutions, alas. Following to take notes, as I may very likely need them next time I am forced to upgrade, on any distro.
Marco
On 2/19/22 11:02, Iosif Fettich wrote:
Hi Fulko,
I'm not sure when it started, but on everything more complicated than print 'Hello World' my perl is failing. For example:
$ perl -e 'use DateTime;' Attempt to reload List/Util.pm aborted. Compilation failed in require at /usr/share/perl5/vendor_perl/namespace/autoclean.pm line 11. BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/namespace/autoclean.pm line 11. Compilation failed in require at /usr/lib64/perl5/vendor_perl/DateTime.pm line 9. BEGIN failed--compilation aborted at /usr/lib64/perl5/vendor_perl/DateTime.pm line 9. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1.
or
$ cpan Attempt to reload Scalar/Util.pm aborted. Compilation failed in require at /usr/share/perl5/Safe.pm line 4. BEGIN failed--compilation aborted at /usr/share/perl5/Safe.pm line 4. Compilation failed in require at /usr/share/perl5/vendor_perl/CPAN.pm line 57. BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/CPAN.pm line 57. Compilation failed in require at /usr/share/perl5/vendor_perl/App/Cpan.pm line 290. BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/App/Cpan.pm line 290. Compilation failed in require at /usr/bin/cpan line 7. BEGIN failed--compilation aborted at /usr/bin/cpan line 7.
Since I last saw it working, all I can do is remember upgrading to F35, or the daily updates.
Can anyone suggest where to start? For example... Why is it trying to reload Scalar::Util?
Try to identify which cpan you're using (the one from Fedora repos installed via dnf or the one from CPAN) and try to reinstall (or remove...) that one.
Looks like you've mixed Perl modules installed from CPAN with others installed from Fedora. That's not always working.
Maybe you get more clues trying the debugger as well,
$ perl -d -e 'use DateTime;'
Best regards,
Iosif Fettich
I have to agree with Iosif.
This reeks of mixed versions.
If this happened to me, I would delete every single module and .precomp and perl itself, including those in $HOME.
Then do a dnf install from the Fedora repo.
Fulko Hew writes:
or
$ cpan Attempt to reload Scalar/Util.pm aborted.
Looks like you have installed additional Perl modules, bypassing Fedora's packaged perl RPMs. This is likely resulted in unintentional corruption or incompatibility with your base Fedora perl installation, in some unknown manner that nobody, I'm afraid, can diagnose for you.
Can anyone suggest where to start? For example... Why is it trying to reload Scalar::Util?
Who knows. Attempting to elicit logic from an illogical state of affairs is unlikely to succeed.
At this point, it might be faster for you to simply wipe everything and reinstall Fedora. An unintentional power loss on my laptop right after an upgrade resulted in an unbootable brick, by default, with some weird complaint. Manually selecting an older kernel from grub completed the boot.
Rather than trying to tinker and figure out WTF, I just wiped and reinstalled. Took only two hours to do. It might be faster for you to do the same.
Afterwards, try not to use cpan in combination with the system-installed perl. First of all, there is a very likely possibility that whatever module you needed, there's already a Fedora RPM for it. Install it, and call it a day.
If you do need a very custom Perl ecosystem, with CPAN and all those bells and whistles: you should build your own Perl core from scratch. Install it somewhere else, in /usr/local maybe. Use CPAN with it, to your heart's content, without touching the system perl.
perl-Scalar-Util is not a rpm fedora package
but what about perl-Scalar-List-Utils which provides perl(Scalar::Util) ?
=========================================================================== Patrick DUPRÉ | | email: pdupre@gmx.com Laboratoire interdisciplinaire Carnot de Bourgogne 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE Tel: +33 (0)380395988 | | Room# D114A ===========================================================================
Sent: Sunday, February 20, 2022 at 2:28 PM From: "Sam Varshavchik" mrsam@courier-mta.com To: "Community support for Fedora users" users@lists.fedoraproject.org Subject: Re: Perl is now failing for me
Fulko Hew writes:
or
$ cpan Attempt to reload Scalar/Util.pm aborted.
Looks like you have installed additional Perl modules, bypassing Fedora's packaged perl RPMs. This is likely resulted in unintentional corruption or incompatibility with your base Fedora perl installation, in some unknown manner that nobody, I'm afraid, can diagnose for you.
Can anyone suggest where to start? For example... Why is it trying to reload Scalar::Util?
Who knows. Attempting to elicit logic from an illogical state of affairs is unlikely to succeed.
At this point, it might be faster for you to simply wipe everything and reinstall Fedora. An unintentional power loss on my laptop right after an upgrade resulted in an unbootable brick, by default, with some weird complaint. Manually selecting an older kernel from grub completed the boot.
Rather than trying to tinker and figure out WTF, I just wiped and reinstalled. Took only two hours to do. It might be faster for you to do the same.
Afterwards, try not to use cpan in combination with the system-installed perl. First of all, there is a very likely possibility that whatever module you needed, there's already a Fedora RPM for it. Install it, and call it a day.
If you do need a very custom Perl ecosystem, with CPAN and all those bells and whistles: you should build your own Perl core from scratch. Install it somewhere else, in /usr/local maybe. Use CPAN with it, to your heart's content, without touching the system perl.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
td;dr version:
A newly dnf updated Perl was now failing to access/load an accessible shared object file in a perl subdirectory of my home. I moved that home subdir out of the way. Now it works. (But I still have to go back and resolve what might now be missing. I.e. What was in that subdir and do I still need it for something?)
On Sat, Feb 19, 2022 at 2:03 PM Iosif Fettich ifettich@gmail.com wrote:
... snip ...
Try to identify which cpan you're using (the one from Fedora repos installed via dnf or the one from CPAN) and try to reinstall (or remove...) that one.
Looks like you've mixed Perl modules installed from CPAN with others installed from Fedora. That's not always working.
I was using the Fedora distributed 'cpan'.
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?
On Sat, Feb 19, 2022 at 2:17 PM Tom Horsley horsley1953@gmail.com wrote:
On Sat, 19 Feb 2022 12:58:50 -0500 Fulko Hew wrote:
Can anyone suggest where to start?
Run the command under strace to see what strange locations it is picking up perl or perl modules from.
I didn't need to. One of my experiments showed me that perl was trying to load a.so file from a home subdir (/home/fhew/perl5...) and it wasn't succeeding. However the file was there and was accessible.
That error led me to google for that, and I found a Bugzilla entry https://bugzilla.redhat.com/show_bug.cgi?id=1590973 that led me to move that subdir out of the way.
And that has resolved the issue.
Now I have the time to go back and look at what and why I needed to install those other libraries.
On Sun, Feb 20, 2022 at 8:30 AM Sam Varshavchik mrsam@courier-mta.com wrote:
... snip ...
Looks like you have installed additional Perl modules, bypassing Fedora's packaged perl RPMs. This is likely resulted in unintentional corruption or incompatibility with your base Fedora perl installation, in some unknown manner that nobody, I'm afraid, can diagnose for you.
Actually, it's more like Fedora installed/upgraded some packages that were incompatible with what was previously installed and running.
Can anyone suggest where to start? For example... Why is it trying to reload Scalar::Util?
Who knows. Attempting to elicit logic from an illogical state of affairs is unlikely to succeed.
At this point, it might be faster for you to simply wipe everything and reinstall Fedora.
Faster. No, I think not. A raw install, usually entails about 2 days of nerve wracking copying migration, tweaking and testing to get back into the working state I was migrating from. I want to avoid that at all costs.
... snip ...
Afterwards, try not to use cpan in combination with the system-installed perl. First of all, there is a very likely possibility that whatever module you needed, there's already a Fedora RPM for it. Install it, and call it a day.
One of the great features of Perl, _is_ CPAN. To ignore CPAN is to ignore most of its vast ecosystem. Sure I understand that Fedora isn't going to re-package every Perl module. Perhaps Fedora people could design a package mechanism that would, in effect, 'cpan install' modules rather than distribute a (static) pre-built module?
If you do need a very custom Perl ecosystem, with CPAN and all those bells
and whistles: you should build your own Perl core from scratch. Install it somewhere else, in /usr/local maybe. Use CPAN with it, to your heart's content, without touching the system perl.
I hear you, but this is the first time in 25 years of Fedora and Perl, that I've ever seen anything like this happen to me.
On Sun, Feb 20, 2022 at 9:32 AM Patrick Dupre pdupre@gmx.com wrote:
perl-Scalar-Util is not a rpm fedora package
but what about perl-Scalar-List-Utils which provides perl(Scalar::Util) ?
That was just a symptom, not the issue. My guess is that while installing a module via CPAN (one that Fedora doesn't distribute) That module needed Scalar::Util, and so it installed it too. That's what CPAN does, it resolves all dependencies, across all of Perl. If I wasn't using CPAN, then a) I would have had to have known that it was going to need Scalar::Utils, b) I would then also have to go and find what Fedora package contained it. And as you showed, the name isn't the same. That would take a lot of work to hunt down the packages that contain the modules. ... repeat for all perl module dependencies. ... and then what do you do when there isn't a Fedora version of the module?
Anyway, problem solved, and I hope these notes might help someone else in the future.
On 2/20/22 07:05, Fulko Hew wrote:
a) I would have had to have known that it was going to need Scalar::Utils, b) I would then also have to go and find what Fedora package contained it. And as you showed, the name isn't the same. That would take a lot
Part b isn't that hard. You can do "dnf install 'perl(Scalar::Util)'".
On Sun, Feb 20, 2022 at 10:14 AM Samuel Sieb samuel@sieb.net wrote:
On 2/20/22 07:05, Fulko Hew wrote:
a) I would have had to have known that it was going to need
Scalar::Utils,
b) I would then also have to go and find what Fedora package contained
it.
And as you showed, the name isn't the same. That would take a lotPart b isn't that hard. You can do "dnf install 'perl(Scalar::Util)'".
Ahh, that's good to know. Now if I could only remember that when I need it! :-)
...
I just found my first example of the issue...
I need DateTime:Event:Sunrise and there isn't a Fedora package for it.
On Sun, Feb 20, 2022 at 16:05, Fulko Hew wrote:
And yes, I was (and always have) installed additional modulesvia CPAN where Fedora doesn't have those modules. (Trouble is thateven when Fedora can deliver one of those packages, they aren'tnamed 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. 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/ (https://stop.zona-m.net/2022/01/the-sorry-sorry-state-of-linux-packaging/) Marco
On 2/20/22 07:38, Fulko Hew wrote:
I just found my first example of the issue...
I need DateTime:Event:Sunrise and there isn't a Fedora package for it.
Careful, there are double colons needed in the name. There's a very handy package called "cpanspec" which helps you package cpan packages into rpms.
In this case, when I first tried it, it gave a list of required packages which were all available in Fedora.
dnf install 'perl(DateTime::Set)' 'perl(DateTime::Span)' 'perl(DateTime::SpanSet)' 'perl(ExtUtils::MakeMaker)' 'perl(Set::Infinite)' 'perl(Test::Exception)' 'perl(Test::More)'
Then I could run (as a user): cpanspec --build --packager me DateTime::Event::Sunrise
This generated an installable rpm.
On Sun, Feb 20, 2022 at 9:46 PM Samuel Sieb samuel@sieb.net wrote:
On 2/20/22 07:38, Fulko Hew wrote:
I just found my first example of the issue...
I need DateTime:Event:Sunrise and there isn't a Fedora package for it.
Careful, there are double colons needed in the name.
Sorry, that was my Perl dyslexia kicking in. Where my brain always gets it wrong between the module names that use a single hyphen versus the file hierarchy that uses a single slash, and the class path that uses double colons. I actually did use double colons when I tried the command, but my fingers broke down while typing my email.
There's a very
handy package called "cpanspec" which helps you package cpan packages into rpms.
In this case, when I first tried it, it gave a list of required packages which were all available in Fedora.
dnf install 'perl(DateTime::Set)' 'perl(DateTime::Span)' 'perl(DateTime::SpanSet)' 'perl(ExtUtils::MakeMaker)' 'perl(Set::Infinite)' 'perl(Test::Exception)' 'perl(Test::More)'
Then I could run (as a user): cpanspec --build --packager me DateTime::Event::Sunrise
This generated an installable rpm.
Thanks for pointing out that app, but I fail to see how having me make an RPM for a Fedora-unsupported module avoids the problem of incompatibilities between newer Fedora sources packages and locally sourced packages (or locally CPAN installed modules) Or am I missing something?
On 2/20/22 21:00, Fulko Hew wrote:
Thanks for pointing out that app, but I fail to see how having me make an RPM for a Fedora-unsupported module avoids the problem of incompatibilities between newer Fedora sources packages and locally sourced packages (or locally CPAN installed modules) Or am I missing something?
The benefit is that it's managed by the package manager, so it's easy to cleanly add, remove, and update it. The alternative methods dump the files in various places and when a problem happens, you have to figure out where those problem files are.
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:
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.
On Mon, Feb 21, 2022 09:21:05 AM -0400, George N. White III wrote:
Open source makes it easy for people to innovate, and we need to encourage experimentation, but we can't have experiments in linux distros.
George,
the core of that post of mine is that what you say has become impossible. That is, it has become IMPOSSIBLE, for users with more than really basic needs, who still are many more than developers buthave other ways to serve the community, to NOT "experiment", wasting against their will much more time than it was the case 10 years ago, whatever distro they choose.
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.
Whatever. The reality still is that they and their equivalents for other languages have made it impossible for anyone on any OS to have a unified front end for package management. And this is not progress wrt 10/15 years ago, no matter how one puts it.
Packages are messy and likely always will be.
Packages are MUCH messier now than before, without any real reason I can recognize as such, and for users this is NOT progress, that's my whole point. And I am not talking newbies. I used to compile from sources tens of packages, back in the 90's/early 00s.
Today, I am forced to spend MORE time than back then to restore a system that does what I need every time I upgrade the distro, because:
a) compiling everything from source would be consume even more time, much more than when "config, make, make install" and manual dependency solving was enough
b) so the least worst way to cope is to endure (every time with different, often undocumented gotchas) ten different packaging systems who couldn't care less to acknowledge that people could need sw from different communities
Sure, software becomes more complex over time. But this doesn't mean that what we have today makes sense.
Marco
On Tue, 22 Feb 2022 at 06:31, M. Fioretti mfioretti@nexaima.net wrote:
On Mon, Feb 21, 2022 09:21:05 AM -0400, George N. White III wrote:
Open source makes it easy for people to innovate, and we need to encourage experimentation, but we can't have experiments in linux distros.
George,
the core of that post of mine is that what you say has become impossible. That is, it has become IMPOSSIBLE, for users with more than really basic needs, who still are many more than developers buthave other ways to serve the community, to NOT "experiment", wasting against their will much more time than it was the case 10 years ago, whatever distro they choose.
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.
Whatever. The reality still is that they and their equivalents for other languages have made it impossible for anyone on any OS to have a unified front end for package management. And this is not progress wrt 10/15 years ago, no matter how one puts it.
I cobbled together a moderately complex software system, originally developed on SGI IRIX64. One part of the system is built around a C++ library that comes and goes from distributions. There are several Fortran programs that use an error handling package which never fully made the transition to Fortran 90. The system also relies on a number of POSIX tools, awk, join, sed, etc.It also required a much more complex NASA package that has not be ported to Windows (and never will be because it contains support for legacy satellite platforms that would be enormously expensive to port to Windows) to extract input data and a couple large programs that are available from distros but built without options I need. I replaced the one program from the NASA package with a Python script for use on Windows, but it depends on several large Python libraries. I end up spending a lot of time testing new Python versions and new libraries to ensure they are still working properly (new versions often have problems, but they generally get fixed without my help).
Porting the system to a new linux distro means working out which libraries aren't packaged. This can be tricky as there are often newer drop-replacements for legacy libraries (aes versus sz is the most recent example).
Packages are messy and likely always will be.
Packages are MUCH messier now than before, without any real reason I can recognize as such, and for users this is NOT progress, that's my whole point. And I am not talking newbies. I used to compile from sources tens of packages, back in the 90's/early 00s.
I agree that it has become much more difficult to port a complex system to linux due to differences in what libraries are packed and in the configure options used for a given library on different distributions. There is also the problem that some distros enable options that don't actually work because they rely on a newer version of other distro package.
Today, I am forced to spend MORE time than back then to restore a system that does what I need every time I upgrade the distro, because:
a) compiling everything from source would be consume even more time, much more than when "config, make, make install" and manual dependency solving was enough
The NASA package I use provides binaries built on CENTOS, but also sources so you can build it on distros that aren't compatible. If the majority of users weren't forced by their institutions to use Windows I would consideri making my package an add-on, su using the NASA libraries and build system (python build scripts for each library that run cmake or configure as required).
b) so the least worst way to cope is to endure (every time with different, often undocumented gotchas) ten different packaging systems who couldn't care less to acknowledge that people could need sw from different communities
Many groups are now using conda-forge and adding packages for the stuff they need.
Sure, software becomes more complex over time. But this doesn't mean that what we have today makes sense.
I participate in a couple user forums. At one time the forums were dominated by questions over details of the algorithms and bug reports. Now, there are many problems related to packing and version conflicts. Linux distros generally reserve "python" for python 2.7, and python3 for the current system python 3.x version, but Anaconda uses "python". There are often multiple python packages with the same or similar names.
Sure that doesn't make sense, but there is no mechanism to force Anaconda to use "python3" or to require unique names for python packages.
On Tue, Feb 22, 2022 09:05:54 AM -0400, George N. White III wrote:
I end up spending a lot of time testing new Python versions and new libraries to ensure they are still working properly (new versions often have problems, but they generally get fixed without my help)...
I agree that it has become much more difficult to port a complex system to linux due to differences in what libraries are packed and in the configure options used for a given library on different distributions....
George,
thanks for sharing your use case, you're doing really interesting work. All I can add is:
- while being surely more complex than what an average Linux newbie needs, what I do is simpler than what you do, and still I too must waste too much time
- thanks for confirming that there is a serious problem
- All I know is that is that it is sorely needed ONE front-end in Linux where one can say, as it was in the golden age of .rpm and .deb, "I need this software. I couldn't care less, and there's nothing bad with it, of which language, build environment, packaging format... this software came from. Just find the damn thing and install it yourself, with any dependency, while I take a nap".
- I don't know if conda is the right theoretical answer. I just know that until there is no awareness from developers and distro integrators (more the former than the latter, probably) of the mess they have put users in, and the will to fix it with conda or anything else, nothing will change
funny historical note about conda: they "stole" (note the quotes, no problem with that) the miniconda name from the RULE project I and others started twenty years ago:
https://www.slideshare.net/mfioretti/rule-ld-roma2004
and also https://spazioinwind.libero.it/marco_web/RULE/installer.html (I have a full static archive of the original RULE website, went offline when I switched VPS, will restore it asap)
Marco
On Tue, 22 Feb 2022 at 12:28, M. Fioretti mfioretti@nexaima.net wrote:
On Tue, Feb 22, 2022 09:05:54 AM -0400, George N. White III wrote:
[...]
- All I know is that is that it is sorely needed ONE front-end in
Linux where one can say, as it was in the golden age of .rpm and .deb, "I need this software. I couldn't care less, and there's nothing bad with it, of which language, build environment, packaging format... this software came from. Just find the damn thing and install it yourself, with any dependency, while I take a nap".
- I don't know if conda is the right theoretical answer. I just know
that until there is no awareness from developers and distro integrators (more the former than the latter, probably) of the mess they have put users in, and the will to fix it with conda or anything else, nothing will change
Linux distros have to focus on the most commonly used packages. Debian may be the exception -- there you can get packages with a smaller user base if someone steps forward to do the work, including contributing to libraries they require.
Cross-distro packagers don't want to make it easy for users to switch back to distro packages (hence python versus python3). Conda-forge is more open to allowing packages with a limited user base.
funny historical note about conda: they "stole" (note the quotes, no problem with that) the miniconda name from the RULE project I and others started twenty years ago:
I vaguely remember RULE. I used to work in a group that ran ocean remote sensing workshops for post-doc level scientists from developing countries. At one time participants had Windows PC's and the course used a linux VM from NASA. I demoed a bare-metal installation on an old PC and advised participants to look for an old unloved and unwanted PC at their home institution on which they could install linux.
Name clashes can often be avoided if people would check that a proposed name is not already in use, and b) consistently use something unique like their organization name as a prefix. If nothing is done such clashes will only increase with time.
and also https://spazioinwind.libero.it/marco_web/RULE/installer.html (I have a full static archive of the original RULE website, went offline when I switched VPS, will restore it asap)
Try a goggle search for "python snap library" and imagine a student whose instructor said "for today's homework, install the python snap library and use it to ....".
If your requirements match those of sufficiently large audience, you might consider organiziing a Fedora spin.
On Mon, 21 Feb 2022 00:22:13 -0800 Samuel Sieb samuel@sieb.net wrote:
On 2/20/22 21:00, Fulko Hew wrote:
Thanks for pointing out that app, but I fail to see how having me make an RPM for a Fedora-unsupported module avoids the problem of incompatibilities between newer Fedora sources packages and locally sourced packages (or locally CPAN installed modules) Or am I missing something?
The benefit is that it's managed by the package manager, so it's easy to cleanly add, remove, and update it. The alternative methods dump the files in various places and when a problem happens, you have to figure out where those problem files are.
A big advantage is that the package manager will complain if you attempt an incompatible update. You will know right away that you need to fix something (even though DNF’s error messages can be hard to decipher).
I learned this the hard way and haven’t used CPAN since. Cpansec is great (as is cpan2port).
Jim