The issue I see is that no package management system I know of handles multiple so versions, they explicitly state packages conflict with each-other even if in principle the so versioning means they would not. Some repositories can handle multiple major so versions and I do think this may provide enough flexibility. I suppose the place of ultimate conflict is the devel packages as multi-version headers would always be in conflict, and I can’t imagine the nonsense one would have to go through to tell autoconf/pkg-config “no wait I want this specific version” in a shared library environment. But in principle there is nothing FHS related limiting multiple versions of a library. It’s an artificial limitation that probably helps ease the lives of package maintainers, it is not a technical limitation imposed by FHS. Sent from my iPhone > On May 22, 2020, at 7:19 PM, Przemek Klosowski via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > On 5/22/20 6:23 PM, Paul Dufresne via devel wrote: >> So let's take an example: >> >> At first you have: >> /pkgs/programA_version1 that have a LD_LIBRARY_PATH that contains /pkgs/libX_version1 >> /pkgs/libX_version1 contains libX, version 1. >> >> Now you "upgrade" libX vesion 2... because each packages is in it's own directory, you create a new directory: >> /pkgs/libX_version2 >> but you do not erase /pkgs/libX_version1 because it is still used by at least one program, programA. >> >> Note that if you were using FHS, you would have to give a version number to the library file itself, because else it would clash with the old one, because they would be it the same directory. > > Yes, and there's nothing wrong with that! In FHS you have > > /lib/libhogweed.so.4 -> libhogweed.so.4.5 > /lib/libhogweed.so.4.5 > /lib/libhogweed.so.5 -> libhogweed.so.5.0 > /lib/libhogweed.so.5.0 > > An application requiring any v.5 links to /lib/libhogweed.so.5 and allows transparent upgrades from say 5.0 to 5.1, and the sad app that really depends on 4.5 links specifically to /lib/libhogweed.so.4.5. Normally a major version bump implies a significant API change, so it doesn't make sense to also have /lib/libhogweed.so -> libhogweed.so.5 because it would be impossible to assure future compatibility, but if someone came up with an API convention that somehow handles this, it is in principle possible and would completely decouple programs from system library versions. > > >> >> Now, we eant to "upgrade" program A to version 2... that means we create: >> /pkgs/programA_version2, while keeping programA_version1... because that's the way to upgrade in a system without FHS. >> >> Now, the new /pkgs/programA_version2 is different than version 1 by the fact that it used the new pkgs/libX_version2 ... that is it's LIBRARY_PATH now contains pkgs/libX_version2, and not pkgs/libX_version1 anymore. >> >> So you try the new version, it works. If nobody use programA_version1, you can delete pkgs/programA_version1 and pkgs/libX_version1 now. > > I think all the cases that you called out are handled with this scheme... and it saves us from the DLL hell with different versions of libs all over the place. > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
