innupgrade for old shared libraries?
julien at trigofacile.com
Thu Nov 25 20:55:47 UTC 2021
>> %ls -la
>> -rw-r--r-- 1 news news 219K sept. 19 16:17 libinnhist.a
>> -r-xr-xr-x 1 news news 1016 sept. 19 16:09 libinnhist.la*
>> lrwxrwxrwx 1 root root 19 sept. 19 16:17 libinnhist.so ->
>> lrwxrwxrwx 1 root root 19 sept. 19 16:17 libinnhist.so.3 ->
>> -r-xr-xr-x 1 news news 94K août 8 2015 libinnhist.so.3.0.0*
>> -r-xr-xr-x 1 news news 137K nov. 26 2017 libinnhist.so.3.0.1*
>> -r-xr-xr-x 1 news news 137K nov. 10 2018 libinnhist.so.3.0.2*
>> -r-xr-xr-x 1 news news 137K nov. 22 2020 libinnhist.so.3.0.3*
>> -r-xr-xr-x 1 news news 137K sept. 19 16:17 libinnhist.so.3.0.4*
> Libraries with the same SONAME should have backwards-compatible ABI, so
> there should be no need to keep old versions.
For a given SONAME with no previous SONAME, I then suggest to keep the
most two recent ones (in date). It will permit supporting a downgrade,
as recalled by Russ.
One can update from INN 2.6.1 to INN 2.6.4 directly for instance, so we
should not remove given version numbers (so.3.0.0, so.3.0.1, so.3.0.2
for instance) but the third most recent and the following ones if any
for a given SONAME.
Comparison should be done on date, not on version numbers, because we
may have the case of someone running INN 2.6.4 (with .so.3.0.4), who
rebuilds INN 2.6.2 (with .so.3.0.2) and installs it. We would not want
to remove .so.3.0.2 because .so.3.0.3 and .so.3.0.4 were also present
(the symlink libinnhist.so to .so.3.0.2 would no longer be valid).
>> -rw-r--r-- 1 news news 1,5M sept. 19 16:17 libinn.a
>> -r-xr-xr-x 1 news news 925 sept. 19 16:08 libinn.la*
>> lrwxrwxrwx 1 root root 15 sept. 19 16:17 libinn.so -> libinn.so.6.0.1*
>> lrwxrwxrwx 1 root root 15 août 8 2015 libinn.so.3 -> libinn.so.3.0.0*
>> -r-xr-xr-x 1 news news 603K août 6 2015 libinn.so.3.0.0*
>> lrwxrwxrwx 1 root root 15 nov. 26 2017 libinn.so.4 -> libinn.so.4.0.0*
>> -r-xr-xr-x 1 news news 718K nov. 26 2017 libinn.so.4.0.0*
>> lrwxrwxrwx 1 root root 15 nov. 10 2018 libinn.so.5 -> libinn.so.5.0.0*
>> -r-xr-xr-x 1 news news 718K sept. 20 2018 libinn.so.5.0.0*
>> lrwxrwxrwx 1 root root 15 sept. 19 16:17 libinn.so.6 -> libinn.so.6.0.1*
>> -r-xr-xr-x 1 news news 725K nov. 22 2020 libinn.so.6.0.0*
>> -r-xr-xr-x 1 news news 725K sept. 19 16:08 libinn.so.6.0.1*
> Here we have different SONAMEs, so different ABI. In Fedora we usually
> keep just one version of a package unless there are very good reasons
> like significant portion of consumers not ported to the new ABI. As
> upstream you might have a different policy. Keeping one older SONAME
> around sounds like a safe policy for upgrades.
Maybe we can keep previous SONAMEs during a period of time, for instance
5 or 10 years?
If it is 10 years, it would mean to remove libraries installed by INN
2.5.3 (released in 2012) when installing INN 2.7.0 (scheduled in 2022).
If it is 5 years, it would be INN 2.6.1 (released in 2016), which may be
a bit too short.
And we always keep the (n-1) SONAME, even if very old.
libinn.so.3 was for INN 2.6.0 (released in 2015) so with that rule, we
would keep .so.3, .so.4, .so.5, .so.6.0.2 (probably for INN 2.6.5, I
still have not checked the right number for it) and .so.7 when INN 2.7.0
is released. Assuming INN 2.6.5 was installed of course; the kept
version numbers would otherwise be different.
We remove .so.6.0.0 and .so.6.0.1, therefore only keeping .so.6.0.2 for
SONAME .so.6 because there is also .so7.
Does it sound a good cleanup to do?
Note that proper library versioning was introduced with INN 2.6.0 so we
do not have many versions in the wild.
« A man who is not married is incomplete; a man who is married is
More information about the inn-workers