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:
pgpGPKwUnTeUa.pgp
Description: PGP signature
