Perl is now failing for me

[Fulko Hew]

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?

[Iosif Fettich]

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

[Tom Horsley]

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.

[M. Fioretti]

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

[ToddAndMargo]

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.

[Sam Varshavchik]

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.

[Patrick Dupre]

perl-Scalar-Util is not a rpm fedora package

but
what about 
perl-Scalar-List-Utils
which provides
perl(Scalar::Util) ?

===========================================================================
 Patrick DUPRÉ                                 | | email: [e-mail]
 Laboratoire interdisciplinaire Carnot de Bourgogne
 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
 Tel: [phone]                    | | Room# D114A
===========================================================================
> Sent: Sunday, February 20, 2022 at 2:28 PM
> From: "Sam Varshavchik" 
> To: "Community support for Fedora users" 
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Fulko Hew]

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  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  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 
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  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.

[Samuel Sieb]

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)'".

[Fulko Hew]

On Sun, Feb 20, 2022 at 10:14 AM Samuel Sieb  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 lot
>
> Part 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.

Re[2]: Perl is now failing for me

[Marco Fioretti]

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

[Samuel Sieb]

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.

[Fulko Hew]

On Sun, Feb 20, 2022 at 9:46 PM Samuel Sieb  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?

[Samuel Sieb]

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.

Re[2]: Perl is now failing for me

[George N. White III]

On Sun, 20 Feb 2022 at 12:55, Marco Fioretti  wrote:
> On Sun, Feb 20, 2022 at 16:05, Fulko Hew  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.

Re[2]: Perl is now failing for me

[M. Fioretti]

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

Re[2]: Perl is now failing for me

[George N. White III]

On Tue, 22 Feb 2022 at 06:31, M. Fioretti  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.

Re[2]: Perl is now failing for me

[M. Fioretti]

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

Re[2]: Perl is now failing for me

[George N. White III]

On Tue, 22 Feb 2022 at 12:28, M. Fioretti  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:
>
> https://www.slideshare.net/mfioretti/rule-ld-roma2004

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.

[James Szinger]

On Mon, 21 Feb 2022 00:22:13 -0800
Samuel Sieb  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