Some large third-party projects are a maintenance headache: they may depend on libraries not used any other Fedora package or need libraries configured with options not needed by other packages.
Many unix package managers ship broken and/or significantly out of date versions of Julia. Please use juliaup or download the official binaries instead
Both Jupyter and Sagemath have active communities that can benefit when members share a common implementation. Linux distros should consider whether resources are better spent insuring that such 3rd party cross-distro packages work well in the given distro instead of efforts to provide libraries unique (or uniquely configured) to support a single application that has its own community.
Octave may be an edge case because it connects to the Matlab community. Octave is often used by linux users who may have Matlab experience in college or at work and want a similar environment on personal systems (or at work when all the licenses are being used).
Yeah, I think this kind of falls under the problem that Objective Review: We integrate programming language stack ecosystems is intended to look at. I don’t have a great solution waiting here, but I feel like there must be some way where we can bring some of the traditional value as a distro (nice integration with other software, ease of install and availability, consistent compiler flags, etc.) while also fitting more nicely with the way various upstreams work.
In an older post here on the forum, related to the maintenance of Sagemath, I suggested a toolbox image. I also tested said image in podman and toolbox. ( Cannot recall if I finished testing in systemd-nspawn but should work as well ).
Linked here :
You are right @gnwiii The community around it’s development is active and I see no reason to not use a container workflow for such a popular tool. Here are container images for the other tools as well.
Sagemath
podman pull sagemath/sagemath podman run sagemath/sagemath <command>
Gnu Octave
podman pull gnuoctave/octave podman run octave/octave <command>
Julia
podman pull julia podman run julia/julia <command>
I think is a really important topic to cover both for container workflows and maintance, but also for keeping up with latest packages.
Out of curiosity, I tried to build sagemath-10.3 from its latest specfile on Fedora 40.
Half of the patches failed to apply and made me doubt whether the other half is still relevant.
In addition, the dependency on tachyon failed for obvious reasons, and this is also understandable as it has not been updated in over a decade, although not difficult to solve.
Then I tried to fix or remove other failing parts of the specfile and eventually passed the %configure stage, however it still failed to build.
Perhaps using some sort of isolation or virtualization is the only realistic way to make it work considering the current resources of the Fedora community.
The build failure is directly related to the flexiblas patch being commented out. You need that one.
Back when I kept sagemath building, it would take several hours of work to adapt to every new version. Since the last successful build was a few versions ago, it wouldn’t surprise me if there were a couple of days worth of work to do to get version 10.3 to build.
There are advantages to having an RPM build of such large packages, but it is a lot of work for sure. In the absence of a group of people willing to put in that work, installing a container, or flatpak, etc. is really the only option.
For a package like that, for a project like Fedora i truly see no other alternative. It stays current and is built by that community. I might have time next week to play some more with the containers but it was poretty seamless FMPOV.
At this point, when I set up a machine for my use of large scientific package collections, once I get Linux up and running I install Mambaforge and run all the complicated stuff in conda environments. They have good support for R now; the only major package that’s missing is RStudio Server, and I can install that in Linux and confgure it to use the R that’s in conda-forge.
From a user’s perspective, I don’t see why the distros should have to package such software at all, when the conda-forge community (and the PyTorch community and NVIDIA and …) have done all of this, and it works the same way on Linux, Windows and MacOS.
Agree, and we should not overlook the implications for the user community. Cross-platform availability fosters a larger community of users whose shared focus is the application area, and narrows the scope of Linux distro user communities to the core functions (filesystems, networking, security, audio, package management, GUI environments).
I’ve been running Silverblue for a couple of months now and that’s exactly the point! Everything should be contained! I use conda-forge for data science because most of the rest of the data science world is composed of Pythonistas and the Python and R (and Julia) communities have effectively merged there. I use Arch for audio because they have the best collection of packaged, up-to-date Linux audio tools. I use Ubuntu 22.04 LTS containers for a lot of experimental things because often third-party tools only test on Ubuntu LTS, RHEL / RHEL knockoffs and maybe SUSE Enterprise.
There is a downside to conda-forge - quite a few utilities, for example CMake, ninja-build, GCC, even CUDA, are duplicated there and have to be in the distros anyway. So you have to decide, “Do I use the distro’s CMake or the conda one?”
In many cases the added tools are different versions, so not really duplicates, and big systems won’t build with Fedora’s tools and libraries due to differences in library versions and build options. Linux distros struggle to find package maintainers so reducing the demands on packagers by expecting users to add storage capacity is a worthwhile tradeoff.
Conda environments, flatpaks, or containers can all avoid clashes with system tools and libraries. See conda installation for Julia and Sagemath mentioned above, also R from conda – see the section on “Creating an environment with R”.
Oh, I quite agree! Disks get more capacity per dollar faster than package maintainers can be recruited and trained. But multiple package management systems only make sense for a user in containers; if you try to do it on the “host”, you’ll run into PATH pollution and bug-chasing time wastage because of multiple versions. Can you tell I’m a happy Silverblue / Bluefin user?
