[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Release now?
From: |
Greg Troxel |
Subject: |
Re: Release now? |
Date: |
27 Feb 2003 15:54:23 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
{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>
- pkg-config support for guile, (continued)
- pkg-config support for guile, Greg Troxel, 2003/02/27
- Re: Release now?, Rob Browning, 2003/02/27
- Re: Release now?, Greg Troxel, 2003/02/27
- Re: Release now?, Rob Browning, 2003/02/27
- Re: Release now?, Greg Troxel, 2003/02/27
- Re: Release now?, Rob Browning, 2003/02/27
- Re: Release now?, Rob Browning, 2003/02/27
- Re: Release now?, Rob Browning, 2003/02/27
- Re: Release now?, Greg Troxel, 2003/02/27
- Re: Release now?, Rob Browning, 2003/02/27
- Re: Release now?,
Greg Troxel <=
- Re: Release now?, Dale P. Smith, 2003/02/27
- Re: Release now?, Dale P. Smith, 2003/02/27
- Re: Release now?, Rob Browning, 2003/02/27
- Re: Release now?, Andreas Rottmann, 2003/02/25
Re: Release now?, Rob Browning, 2003/02/24
Re: Release now?, Marius Vollmer, 2003/02/25