soname change policy proposal

Michael Schwendt bugs.michael at gmx.net
Sat Jul 1 17:31:41 UTC 2006


On Sat, 01 Jul 2006 17:54:07 +0200, Hans de Goede wrote:

> I think you are trying to make this failproof in a totally over the top
> way.

Totally over the top is when SONAME changes or API changes are introduced
into release branches _without_ prior communication or without clear
benefit.

> The end result being that nobody will do a soname bump in the
> non-devel branch possible keeping nice packages out non devel branches
> because they need a newer version and/or keeping bugs in the non-devel
> branch because releasing the bugfix version would require the maintainer
> todo some kinda big and long ceremonial dance.

On the contrary, packagers switching BR from foo-devel to compat-foo-devel,
not getting any bug fixes, then sticking to compat-foo-devel, with the
result that there are multiple instances of "foo" in a release branch,
some with -devel packages, others not. No fun!

> I wrote this with cases like directfb in mind where upstream changes the
> soname every!  release. 

This is an education problem. Contact upstream and lobby for a smarter
release scheme. I've seen library authors who just didn't care much about
how their version info ended up in the soname in an
inappropriate/unexpected way.

Also, a single ugly case does not justify rushing things and coming up
with a general policy which opens up the flood-gates for many other
compat-libfooX packages to enter a distribution.

Much of this is about _release branches_ of the distribution. And I really
would like to see _who_ does the needed investigation as whether and how a
new library breakes API/ABI and so on _before_ publishing rushed
compat-foo packages.

> The whole idea behind my policy proposal was to
> have a sane and reasonably* safe policy, while at the same timing not
> making it nearly impossible for maintainers to actually do an soname change.

IMO, many maintainers don't do any ABI/API checks at all when they release
upgrades. Similarly, they don't compare the feature set of released
packages with the packages to be released.

> *100% safe does not exist, get that stupid notion of 100% safe out of
> your head please

It's not stupid. It's a different point of view.
 
> As I also wrote a API change which causes non trivial to fix build
> errors, makes it mandatory to add a -devel sub package to the compat
> package, so in the security problem case the fixed package can build
> against this -compat-devel package.

Which a) must co-exist with the new -devel package, must co-exist with
further compat -devel packages (because you don't limit the number of
compat packages), and b) can be a non-trivial thing to create (e.g. think
of moving headers, renaming helper scripts, libfoo.so points to most
recent SONAME).
  
> But I've learned from your and other reactions that there is appearantly
>  no support on the list for a balanced soname policy. With the end
> result being that there probably isn't going to be any policy at all.
> 
> I must say I'm disappointed in the lack of the ability to see the
> balance of things here on the list.
> 
> Because of this will probably be my last post in this thread.

For some topics it needs quite some endurance before a satisfactory
solution is developed.




More information about the fedora-extras-list mailing list