Hi Fulko, 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 2/19/22 11:02, Iosif Fettich wrote: 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.

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(a)gmail.com&gt; wrote: ... snip ... 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(a)gmail.com&gt; wrote: 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(a)courier-mta.com&gt; wrote: ... snip ... Actually, it's more like Fedora installed/upgraded some packages that were incompatible with what was previously installed and running. 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 ... 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 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(a)gmx.com&gt; wrote: 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 Sun, Feb 20, 2022 at 10:14 AM Samuel Sieb <samuel(a)sieb.net&gt; wrote: 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 9:46 PM Samuel Sieb <samuel(a)sieb.net&gt; wrote: 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 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 Mon, 21 Feb 2022 00:22:13 -0800 Samuel Sieb <samuel(a)sieb.net&gt; wrote: 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

On Sun, 20 Feb 2022 at 12:55, Marco Fioretti <mfioretti(a)nexaima.net&gt; wrote: 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. 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

On Tue, 22 Feb 2022 at 06:31, M. Fioretti <mfioretti(a)nexaima.net&gt; wrote: 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). 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. 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). Many groups are now using conda-forge and adding packages for the stuff they need. 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. -- George N. White III

On Tue, 22 Feb 2022 at 12:28, M. Fioretti <mfioretti(a)nexaima.net&gt; wrote: 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. 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. 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. -- George N. White III

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(a)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(a)courier-mta.com&gt; > To: "Community support for Fedora users" <users(a)lists.fedoraproject.org&gt; > 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(a)lists.fedoraproject.org > To unsubscribe send an email to users-leave(a)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 >