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