On 5/22/20 4:22 PM, Parker Gibson wrote:
I don’t think this is specifically about FHS as it is about shared library management. The underlying hierarchy defined in FHS doesn’t make the dictations about version management that you seem to indicate, nor are the major problems with maintaining multiple api compatible versions of shared libraries solved with a new hierarchy.
Ok... I am a novice about shared libraries... but here I think how it is
supposed to work... more or less in Nix.
Now I do believe the reason you need to give a version to shared
libraries is because of the FHS. Because FHS suggest to regroup
libraries inside a specific directory and/or directories. But if you
have a common directory that contains every packages inside their own
directory, things because simpler because the directory identify
uniquely a library.
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.
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.
_______________________________________________
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
