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: packaging the add-on libs... Date: 11 Oct 2002 13:10:03 -0400 Sender: guile-devel-admin@gnu.org Message-ID: References: <87vg4aevgx.fsf@raven.i.defaultvalue.org> <20021010071246.GA29109@www> <87lm56co8t.fsf@raven.i.defaultvalue.org> <20021011094150.GA3235@www> <87vg490x7p.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1034356257 18757 127.0.0.1 (11 Oct 2002 17:10:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 11 Oct 2002 17:10:57 +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 1803JQ-0004sO-00 for ; Fri, 11 Oct 2002 19:10:56 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 1803JZ-0000ZP-00; Fri, 11 Oct 2002 13:11:05 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 1803Ij-0000KU-00 for guile-devel@gnu.org; Fri, 11 Oct 2002 13:10:13 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 1803Ib-0000F6-00 for guile-devel@gnu.org; Fri, 11 Oct 2002 13:10:09 -0400 Original-Received: from fnord.ir.bbn.com ([192.1.100.210]) by monty-python.gnu.org with esmtp (Exim 4.10) id 1803Ia-0000Eq-00 for guile-devel@gnu.org; Fri, 11 Oct 2002 13:10:04 -0400 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id A7B273F11; Fri, 11 Oct 2002 13:10:03 -0400 (EDT) Original-To: Rob Browning In-Reply-To: Rob Browning's message of "Fri, 11 Oct 2002 11:14:18 -0500" Original-Lines: 62 X-Mailer: Gnus v5.7/Emacs 20.7 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1529 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1529 Even though this library issue seems to me like a potentially serious impediment to being able to upgrade from one version of guile to another gracefully, especially if guile has a lot of add-on libs provided by third parties, after talking to Bill, it seems that although going with libguile12-foo-bar would be likely fix the problem for guile, it still wouldn't address the same problem for all the other non-guile libs on the system. i.e. what about opengl, libc, X etc. So I'm wondering if perhaps I'm just coming to fully apprehend what is in fact a common unix problem (when inter-library dependencies are involved), one that people just don't think about very often, and one that perhaps it's not guile's job to fix. Not sure. What do others think? I think all grief due to linking with guile really is guile's problem to solve. The other packages have to support either multiple versions or be nearly 100% compile-time compatible with correct older source. With libc, for example, there is a notion that programs compile against the latest headers/libs, and that this latest version is compile-time compatible with programs written for previous versions. Then, one keeps old e.g. libc.so.3 around. For libc, X11 and things like that (at least on BSD - I haven't used Linux in a while) this really is the case and things work fine. With guile, the problem is that a program written for guile 1.4 will not necessarily compile against guile 1.6, due to removal of deprecated stuff and interface changes. While it might be nice to avoid this, guile isn't as mature as libc. This lack of compatibility causes guile to have the obligation to support simultaneous installation of 1.4 and 1.6, at least until all the packages that want 1.4 have --without-guile added to their control files :-) Seriously - that's what I suspect would happen. I think we should strive for a situation where package maintainers can easily have them both, and then programs can get upgraded to use 1.6 'soon', rather than having a huge flag day. I'm less worried about guile-gtk, since that tends to get dynamically loaded from a scheme script. It's things like gnumeric, which on FreeBSD links with 47 libraries, but not guile. Gnumeric source supports guile, but the pkg maintainer turned it off for some reason. This is what I'd like to avoid - IMHO guile should strive to make it easy for others to not only write code to use it, but to package with it. I suggest glib 1.2 and glib 2.0 as an example that is similar to guile - a library used by lots of things, where 1.2 is still in wide use due to programs that haven't been updated yet. Of course, glib has more mindshare than guile, but I think this is where we want to go. We might even use pkgconfig, which has support for finding versions at least/most various values, and would avoid the guile-config name collision. Really, I'm arguing for putting the guile version number in the names ($(prefix)/include/guile16 and all). Programs using guile-config and later pkg-config hopefully should not be put out by this. Sorry for rambling on again... Greg Troxel _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel