Re: Re[2]: Perl is now failing for me

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 22 Feb 2022 at 06:31, M. Fioretti <mfioretti@xxxxxxxxxxx> 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.  
 
--
George N. White III

_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux