Re: Release now?

[Greg Troxel]

  Putting the guile version in the lib name would fix that too, but I
  think there's still a reasonably strong sentiment against
  libguile-12-gwrap-glib-2-gl-3-whatever-4.

But is the sentiment well founded?  We've gone down the path of lib
symlinks, and it seems that it really is pretty hairy.

I hold up glib 1.2/2 as an example of a low-pain solution to what
would otherwise have been a very painful and chaotic transition.
Right now we are perhaps 0.2 to 0.3 of the way through it, and tons of
people have both versions - and both versions of dependent stuff like
ORBit - installed at the same time.  Over time more libraries will
move to the glib2 world, and programs as all the libraries are
available, and eventually people won't need glib 1.2.  Granted, this
is way more complicated than guile, but it's an excellent example of a
long chain of library dependencies when the base library has a major
change.  Granted, you can't do this often, and guile should try to do
it no more often than once every 5 years, but the coping mechanism
seems to work.

And I would suggest not keying on major numbers, but on compile time
changes, and thus the release numbers.  This only need be for when
'recompile everything' isn't a good answer.  libguile14 and libguile16
will be less confsing, IMHO.  Or does debian insist on upgrading a
package without upgrading things that depend on it?  If so, I think
one has to have a new package name that can coexist on every
incompatible change.  (NetBSD's make update does a pkg_delete -r and
then rebuilds all the depending packages.)


        Greg Troxel <address@hidden>