innupgrade for old shared libraries?

Julien ÉLIE julien at trigofacile.com
Thu Nov 25 20:55:47 UTC 2021


Hi Dominik,

>> %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 ->
>> libinnhist.so.3.0.4*
>> lrwxrwxrwx 1 root root    19 sept. 19 16:17 libinnhist.so.3 ->
>> libinnhist.so.3.0.4*
>> -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.

-- 
Julien ÉLIE

« A man who is not married is incomplete; a man who is married is
   finished. »


More information about the inn-workers mailing list