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.