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.
