On Fri, 8 Jun 2001, Michèl Alexandre Salim wrote: > The libraries are only supposed to be used to port > programs to the upcoming GNOME 2 platform, do you > really think we should LART the GNOME developers for > this while they are busy trying to bring it out?
If they are going to release these libraries to the public -- /yes/. The fact that they're 'development' libraries doesn't change the nature of the problem once we've inflicted it on our users, and Debian has no reasonable way to manage sharedlib dependencies when the same soname is used for incompatible libraries (read: there is no reasonable way to do it). If, OTOH, it's contrary to the wishes of the developers that these libraries be made available for wider testing, then perhaps they simply should not be packaged for Debian at this point. The sonames for gtk+ are not reasonable regardless of the 1.3 development series, because they're tied to 'versions' in the stable releases as well. Or were there no gtk+ functions at all that changed ABI between 1.0 and 1.2.x? > > If they want to call the upstream package 'gtk > > 1.3.x' to indicate where in the > > development cycle they are, that's fine; but the > > library soname should not be > > governed by marketing, and upstream /should/ be > > LARTed for this. > *sigh* perhaps not such a good idea, packaging > preview-type packages for Debian. Note that both Red > Hat and Mandrake seems to have no difficulty just > calling the packages (lib)gtk+2 and (lib)glib2 - if > you link against them you should be ready to take the > flak if the interfaces change anyway. If it sees the public eye, and it's binary-incompatible, it merits its own major so number. Anything else is a hazard for our users, regardless of what developers think of the situation. And RedHat is allowed to do what it wants to with its own packages -- Debian didn't get its reputation as a high-quality distribution by following RedHat's lead. Steve Langasek postmodern programmer
