On Tue, 22 Feb 2022 at 06:31, M. Fioretti <mfiore...@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. -- George N. White III
_______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
