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
