[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RFC: rpm auto-glib version enforcement



On Sun, Mar 20, 2005 at 01:03:34PM -0500, Owen Taylor wrote:
> On Sun, 2005-03-20 at 18:20 +0100, Axel Thimm wrote:
> > On Sun, Mar 20, 2005 at 11:39:34AM -0500, Owen Taylor wrote:
> > > On Sun, 2005-03-20 at 16:45 +0100, Axel Thimm wrote:
> > > 
> > > > > Thoughts?
> > > > > Is this feasible to implement in a clean way?
> > > > > Will this fail in any corner cases?
> > > > 
> > > > Supporting a broken library versioning scheme by automated rpm
> > > > workarounds doesn't sound like a good idea. You are better off trying
> > > > to educate upstream authors to start bumping up the major version
> > > > every decade or so ...
> > > > 
> > > > If you start doing so with glib2 you'l have to do the same with pango,
> > > > gtk2, atk, ... (... doesn't stop ...)
> > > 
> > > Why would we change the major version of GLib when we haven't broken
> > > binary compatibility? 
> > 
> > Isn't compatibility broken (be it forward or backward), if I build
> > against glib 2.6, but ldd still allows runtime linking against glib
> > 2.4 which is missing symbols?
> 
> Not under any normal definition of compatibility break.

That's like splitting hairs ;)

The bottom line is that there is breakage. The pieces lie around in
bugzilla and Warren's hands. Whether we call it compatibility
breakness or otheriwse broken is secondary (although I would call this
broken forward compatibility).

> Normally, extending the compatibility of a library is considered to
> be permissible.

The proper use of sonames is to define an explicit set of signatures
and symbols, no more no less. Unfortunately this is being tresspassed
all the time so that doing so has become normal. For some libs (like
glibc) this would indeed be very cumbersome, as each change would bump
up the lib's major.

Extending the interface of the library is backwards, but not forwards
compatible. You always break forward-compatibility when not changing
the soname.

> It would be hard to make progress otherwise. soname changes to base
> libraries are very bad news.

That's why base libs should very carefully be considered for interface
changes. But if there needs to be one, you need to bite the
soname-bumping bullet, or live with breaking forward-compatibility.

I mean, look at glib2, it hasn't bumped it's major since RH7.3 and I
only checked that far back. It is quite possible, that at the end
glib2 will have the same soname over a decade, with the newer lib
being 10 times as big ...

> Symbol versioning (in the original Solaris version, not the extended
> GNU version) was intended to allow labeling new symbols in a new
> version of a library as such, but it's hard to use in a
> cross-platform library.

Anyway, probably the sanest thing to do is to accept forward
compatibility breakage and tell people mixing rawhide, fc3 and fc4t1
not to do so. Nothing breaks under normal usage, only the use cases
where users were to impatient and pulled in a partial rawhide onto their
system.
-- 
Axel.Thimm at ATrpms.net

Attachment: pgp00130.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]