> > Thanks to soname, library are perfect use case for parallel installation > > of multiple versions. > > +1 > > We could go a step further and extend rpm and dnf to support multiple > versions of same named packages for installation. This is doable but Both rpm and dnf can do that, try running `rpm -qa kernel`. As long as same-name packages don't conflict it's ok. > not necessarily trivial. Upgrades would need a way to specify what > package NVR they are upgrading (doable) and dependencies, requires, and > obsoletes would need to be reviewed to ensure you don't wipe out a > version you want installed. Plus more. Solvable and the same end > result for users, just a different approach. The problem with parallel installation is that dnf (formerly yum) only offers a narrow option for parallel installation. But probably a plugin could do that. The real problem is so-called modularity. I support the goal of modularity, but not its vague name and neither its implementation from what I could grok. As soon as two "leaf" modules share a dependency it falls apart as this thread starting point shows. Parallel-installable libraries, whether or not packages are named following Debian's convention, are also not a problem. Either this is explicitly supported by the build system (e.g. usually autotools and pkg-config would) or otherwise it can be "forcefully enabled" in the RPM spec. And that doesn't prevent us from having parallel-installable devel packages too, but someone will likely have to give up the global /usr/include namespace (or different stack equivalent). The problem that fails every attempt at squaring dependencies is their quadratic nature. In the case of lagging upstreams, the First principle mandates that we help dependent upstream move forward. In the legitimate case of multiple living "streams" (another word I find too vague) where N streams may be supported simultaneously, then parallel installation is a better solution, not just availability. But but but... Not everyone can take the single global namespace at once and nobody wants to run gccX.Y on Fedora or RHEL, and update-alternatives (or insert any other attempt) doesn't bring the convenience of running gcc and expect TheRightThing(tm) out of the box. At best it delays the problems. Dridi _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
