Re: Release now?

[Greg Troxel]

{list: I have received no hate mail for ranting so I presume this is
welcome; feel free to tell me otherwise!}

  > 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.

  How do they handle it, and do they have the same dynamic-link issues?
  Also, how do they handle the app1 -> libfoo -> libgtk, and app1 ->
  libbar -> libbgtk with respect to upgrading, during the the period
  when libfoo has been recompiled against the new libgtk, but libbar on
  the system hasn't -- do they just require all libraries in the chain
  to mention the versions of all the other libs they're linked against?

libfoo stays with glib/gtk, and libfoo2 is built against glib2/gtk2.
For some things, the libraries have more substantial changes and have
entirely new names (see linc below, which is a 2-world thing only):

For foo = ORBit:

poblano gdt 997 ~ > ldd /usr/pkg/lib/libORBit.so
/usr/pkg/lib/libORBit.so:
         -lglib.13 => /usr/pkg/lib/libglib.so.13
         -lm.0 => /usr/lib/libm387.so.0
         -lm.0 => /usr/lib/libm.so.0
         -lintl.0 => /usr/lib/libintl.so.0

poblano gdt 1010 ~ > ldd /usr/pkg/bin/orbit-idl
/usr/pkg/bin/orbit-idl:
         -lglib.13 => /usr/pkg/lib/libglib.so.13
         -lIDL.0 => /usr/pkg/lib/libIDL.so.0
         -lgmodule.13 => /usr/pkg/lib/libgmodule.so.13
         -lm.0 => /usr/lib/libm387.so.0
         -lm.0 => /usr/lib/libm.so.0
         -lintl.0 => /usr/lib/libintl.so.0
         -lc.12 => /usr/lib/libc.so.12

poblano gdt 998 ~ > ldd /usr/pkg/lib/libORBit-2.so
/usr/pkg/lib/libORBit-2.so:
         -lm.0 => /usr/lib/libm387.so.0
         -lm.0 => /usr/lib/libm.so.0
         -liconv.3 => /usr/pkg/lib/libiconv.so.3
         -lintl.0 => /usr/lib/libintl.so.0
         -lglib-2.0.200 => /usr/pkg/lib/libglib-2.0.so.200
         -lgobject-2.0.200 => /usr/pkg/lib/libgobject-2.0.so.200
         -lpthread.14 => /usr/pkg/lib/libpthread.so.14
         -lgthread-2.0.200 => /usr/pkg/lib/libgthread-2.0.so.200
         -llinc.1 => /usr/pkg/lib/liblinc.so.1
         -lgmodule-2.0.200 => /usr/pkg/lib/libgmodule-2.0.so.200
         -lpopt.0 => /usr/pkg/lib/libpopt.so.0

poblano gdt 1011 ~ > ldd /usr/pkg/bin/orbit-idl-2
/usr/pkg/bin/orbit-idl-2:
         -lpopt.0 => /usr/pkg/lib/libpopt.so.0
         -lm.0 => /usr/lib/libm387.so.0
         -lm.0 => /usr/lib/libm.so.0
         -liconv.3 => /usr/pkg/lib/libiconv.so.3
         -lintl.0 => /usr/lib/libintl.so.0
         -lglib-2.0.200 => /usr/pkg/lib/libglib-2.0.so.200
         -lIDL-2.0 => /usr/pkg/lib/libIDL-2.so.0
         -lgobject-2.0.200 => /usr/pkg/lib/libgobject-2.0.so.200
         -lgmodule-2.0.200 => /usr/pkg/lib/libgmodule-2.0.so.200
         -lc.12 => /usr/lib/libc.so.12

There are 2 parallel worlds, one rooted on glib 1.2, and one on
glib-2.0.
This indeed doesn't scale, but it's the underlying interface changes
that break compiling that don't scale.  But it isn't quite that bad,
since in the guile world one would have the last guile-gtk version
that worked with guile 14, and one that works with 16.  Then there is
gnome-guile that does glib2/gtk2/ORBit2, and probably that would be
built for the new guile only.

  Well it's actually the major numbers that are required to indicate
  binary compatibility, so they're the most "correct" indicator in
  general.  However in guile, we've committed to changing all the lib
  major numbers with each major release, so they're effectively
  equivalent.

Consider a change that breaks binary compatibility but not compile
compatibility, say because there was a function and now it's a macro
and invokes some compatibility glue.  You have to bump the so number,
but upgrading the guile version doesn't require upstream maintainers
to do anything different, except maybe recompile.  This kind of change
doesn't hurt that badly in the package maintainer viewpoint, since it
doesn't force having to be able to compile against two versions at once.

  One thing to keep in mind is that with a source-based distribution
  like bsd or gentoo, many of these problems go away.  Having to support
  multiple versions of installed binary packages definitely complicates
  things.

It does, but named versions does this.  It looks ugly, but that's
because with a chain of n libs, you have 2^n versions.

Perhaps this is all a red herring and we can preserve compile-time
compatibility adequately.  Keeping the old libs around seems to be a
good solution for running old binaries.  In the specific case of
Gnucash, what about 1.6 made gnucash 1.6.8 not buildable, and was that
something that wasn't deprecated in 1.4?  We may be solving the wrong
problem.

        Greg Troxel <address@hidden>