Re: library-related policy question
On Sun, Sep 06 2009, Russ Allbery wrote:
> "Nikita V. Youshchenko" <yoush@debian.org> writes:
>
>> This does not help in a corner case.
>
>> Issue I am looking at is:
>> - a library used to export a symbol, it was visible in objdump -T output,
>> - at some point, upstream decides that this symbol should be removed,
>> claiming that "it was not ever included in any public APIs".
>> - but this results into binary stop working.
>
> We have done this in the past in Debian without changing the SONAME in
> places where compatibility of SONAME with other distributions is
> important. Specifically, libkrb53 removed several private symbols and we
> didn't change the SONAME. *However*, if you're thinking about doing that,
> you have to both be quite sure that the number of packages using that
> symbol is very limited and rare *and* coordinate that change with all of
> those packages, which will probably mean adding Breaks to the new version
> of the shared library.
>
> Usually this is more hassle than it's worth, but diverging from upstream
> on SONAME can also be an annoying long-term maintenance problem. The more
> central the library (and hence the larger the transition if it changes
> SONAME), the more it's worth putting some effort into avoiding changing
> the SONAME.
While coordinating with other packages is nice, it is not nice
to break user created packages either. Being systems integrators we
sometimes get myopic about only being concerned with breakage in "our"
product, but we should also have care that our users too might actually
use the libraries we ship. Coordinating with all users is a far harder
task.
manoj
--
The only really decent thing to do behind a person's back is pat it.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: