Re: library-related policy question
Manoj Srivastava <srivasta@debian.org> writes:
> On Sun, Sep 06 2009, Russ Allbery wrote:
>> 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.
Right, when we did this for libkrb53 (and by "we" I mean mostly Sam), it
was part of coordinated effort with upstream to remove the deprecated
symbols from the library exports, and upstream was also reaching out to
all the users as well. The symbols being removed hadn't been prototyped
unless you defined KRB5_DEPRECATED and then were removed entirely from the
headers before being removed from the exports, and there was a lot of
advance warning across multiple releases.
It's almost never worth the effort to avoid the SONAME change.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: