For CoCalc, where we have a bunch of different specific versions of Sage pre-installed that all stay stable over *years*, we run a 1-2 pages long "./configure ..." command before I even do "make". At the top it starts with
--with-system-python3=no \ --with-system-r=no \ --with-system-primecount=no \ --with-system-primesieve=no \ --with-system-qhull=no \ --with-system-cmake=no \ ... … so,that's why R, Python interpreter, and other stuff is independent. … We should definitely check if there is more I could make independent. I mean, technically it's not independent, because some underlying libs are shared, but there are certainly less surprises and the dependency graph is not a wide blinking christmas tree. What we are not doing is sharing Sage across linux editions. i.e. 20.04 will have a couple of Sage installs and with 22.04 there will be a new 9.6 one. But that's not the issue in the thread. Could there be a single option to the Sage build system such as: "--without-system" that disables all system libraries, and hence behaves exactly like Sage used to? Is there already such an option that I don't know about? William On Mon, Jul 25, 2022 at 12:44 PM Nils Bruin <nbr...@sfu.ca> wrote: > > On Thursday, 21 July 2022 at 11:52:42 UTC-7 Nils Bruin wrote: >> >> On Thursday, 21 July 2022 at 11:31:35 UTC-7 Matthias Koeppe wrote: >>> >>> >>> You really just need to stop your distribution from automatically >>> uninstalling the old shared library packages when you do upgrades. Both the >>> old version (needed for your from-source installation of Sage) and the new >>> version (needed as dependencies of upgraded system packages) can coexist in >>> your system. >>> >> >> Right .. but that would require telling the system which libraries need to >> be preserved ... I guess one could collect the dependencies by a liberal ldd >> application, but then one would need to query the package manager which >> packages provide the requisite library files and then somehow register those >> packages *are* dependencies ... I guess that could be done by building a >> placeholder package (rpm or deb) that declares all the specific >> dependencies. And to "declare" these, one could install that package. Upon a >> reconfigure+rebuild, one could uninstall the old placeholder, recompute the >> new dependencies, and install a new placeholder ... > > > Ouch ... and it looks like this wouldn't even work: if I try > > dnf whatprovides /usr/lib64/libflint.so.17 > > I get: > > flint-2.9.0-1.fc36.x86_64 > > and similarly > > dnf whatprovides /usr.lib64/libflint.so.16 > flint-2.8.4-2.fc36.x86_64 > > Hence, if a compiled-from-source sagemath were to declare its dependencies to > the package manager it would have to do so by depending on a *specific > version* of flint, and hence "updating" flint should lead to a dependency > conflict. As long as fedora doesn't allow two different version of flint to > be installed at the same time (and the fact that flint-2.9 "upgrades" > flint-2.8 suggests that it won't), we'd need a version lock: just keeping an > unmanaged so-file hang around in space that's supposed to be managed by a > package manager would lead to a rather messy system state. > > So, based on that, I think build-from-source using these kinds of system > resources should actually *not* be a recommended install method: > build-from-source should have its less stable prerequisites satisfied by some > separate environment -- possibly/likely conda. Resources/libraries such as > libflint are clearly *only* managed and provided by the OS in a way that is > appropriate for other OS-managed/packaged software. Turns out there's still a > niche for sage-the-distribution; possibly replaced by > sage-in-conda-the-distribution. Can we get sage-on-conda modified so that it > works nicely with git-trac, so that a sage-conda container can be used for > development? I would be very interested in a guide to that. > > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/6aea8da4-bd04-4eda-914a-c04a6fcbb4e6n%40googlegroups.com. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CACLE5GDv4ntTNay8j9UgOPrAyn_PpExNy4FPRyHt_bKc1RFFcA%40mail.gmail.com.
