[going on on debian-devel, to stop spamming personal mailboxes and hopefully get good advice] Le mar 04/02/2003 à 19:39, Rob Browning a écrit : > Josselin Mouette <joss@debian.org> writes: > > > Well, this sure has its limitations, but it is not needed by all > > libraries, and it is just a transition measure : the extra text can be > > dropped at the next soname change, or when another major dependency > > changes its soname. > > If we were to do this, one concern I would have is that many of these > libraries use libtool. AFAIK libtool only allows integer CURRENT, > REVISION, and AGE numbers. How would we choose these? I did consider > the possibility of using libtool's -release to choose a specific > soname, but unless I'm misunderstanding, we'd have to modify a bunch > of apps/libs and then we'd be far outside the upstream > naming/numbering sequences. I'm not talking afout changing the SONAME, which would break binary compatibility with upstream and other distributions, and we don't want that. I'm just talking about changing the package names, without changing anything else. > > The case of gwrap is indeed tricky, but do binaries building against > > it have to link themselves on glib ? > > I suspect they may -- consider an app like guppi. If it used > g-wrap-glib, then it would have to link against that, and it would of > course also be directly linked against glib. Ick. This case is quite ugly. I don't know if we can come up with an elegant solution. > > If it is not the case, such a change is not needed. The case of > > guile is more like that of the C++ ABI, as software linking to guile > > libraries also need to link against guile. > > Well, they don't actually have to link against guile. An app is > welcome to *just* link against libguile-foo, or libg-wrap-bar, but > it'll still almost certainly be indirectly dependent on libguile's > soname b/c of the SCM transfer issue. This would be another reason to change the package names. If an app links to libguile-foo without linking to guile, it may break unexpectedly when libguile-foo becomes linked to another guile version. > I guess I had been thinking that we might just get all the new > packages built against the new guile and in the staging area and then > upload them en-masse. AFAIK, the old libguile can stay on the system, > it shouldn't hurt anything, and any apps that were *only* linked > against the old libguile, or any closed set of packages that only > depend directly or indirectly on the old libguile should still be > fine. It is only when you have an app or a lib that straddles both > versions that there's problem, but that's not just a guile problem, > that's the case with guile, gtk, glib, libc, perl, etc., and AFAIK > with each of those (unless linux/C somehow drastically change their > linking models), we just have to deal with a period of transition > where some higher level apps/libs are broken in unstable. The problem is that this way, we break partial upgrades. I'm not questioning the staging area, which will only do good, but users don't always upgrade their systems en masse, and if the conflicts are not explicitly handled, they can get random segfaults. Regards, -- .''`. Josselin Mouette /\./\ : :' : josselin.mouette@ens-lyon.org `. `' joss@debian.org `- Debian GNU/Linux -- The power of freedom
Attachment:
signature.asc
Description: PGP signature