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@lists.fedoraproject.org> 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
