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
Attachment:
signature.asc
Description: This is a digitally signed message part
