From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.devel Subject: Re: Release now? Date: 27 Feb 2003 15:54:23 -0500 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <87of50tdcz.fsf@raven.i.defaultvalue.org> <873cmbpyij.fsf@raven.i.defaultvalue.org> <873cm9oe9k.fsf@raven.i.defaultvalue.org> <87r89tlf07.fsf@raven.i.defaultvalue.org> <87isv5leom.fsf@raven.i.defaultvalue.org> <873cm9lcg2.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1046379498 18361 80.91.224.249 (27 Feb 2003 20:58:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 27 Feb 2003 20:58:18 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18oV4N-0004Ze-00 for ; Thu, 27 Feb 2003 21:55:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18oV47-0008QS-00 for guile-devel@m.gmane.org; Thu, 27 Feb 2003 15:55:39 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18oV3N-00080g-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 15:54:53 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18oV31-0007A4-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 15:54:39 -0500 Original-Received: from fnord.ir.bbn.com ([192.1.100.210]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18oV2u-00072K-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 15:54:24 -0500 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id EDE2E871; Thu, 27 Feb 2003 15:54:23 -0500 (EST) Original-To: Rob Browning In-Reply-To: <873cm9lcg2.fsf@raven.i.defaultvalue.org> Original-Lines: 102 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2006 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2006 {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 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel