RFC: rpm auto-glib version enforcement

[Owen Taylor]

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. Normally,
extending the compatibility of a library is considered to be
permissible. It would be hard to make progress otherwise. soname changes
to base libraries are very bad news.

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.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050320/00ae34e1/attachment.sig>