From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: packaging the add-on libs... Date: Fri, 11 Oct 2002 11:14:18 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <87vg490x7p.fsf@raven.i.defaultvalue.org> References: <87vg4aevgx.fsf@raven.i.defaultvalue.org> <20021010071246.GA29109@www> <87lm56co8t.fsf@raven.i.defaultvalue.org> <20021011094150.GA3235@www> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1034352975 2834 127.0.0.1 (11 Oct 2002 16:16:15 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 11 Oct 2002 16:16:15 +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 1802SQ-0000iN-01 for ; Fri, 11 Oct 2002 18:16:10 +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 1802RY-00029Z-00; Fri, 11 Oct 2002 12:15:16 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 1802Qi-0001LA-00 for guile-devel@gnu.org; Fri, 11 Oct 2002 12:14:24 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 1802Qe-0001If-00 for guile-devel@gnu.org; Fri, 11 Oct 2002 12:14:22 -0400 Original-Received: from n66644228.ipcdsl.net ([66.64.4.228] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 1802Qd-0001Ge-00 for guile-devel@gnu.org; Fri, 11 Oct 2002 12:14:19 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id CE27D17EA; Fri, 11 Oct 2002 11:14:18 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 908E199D; Fri, 11 Oct 2002 11:14:18 -0500 (CDT) Original-To: tomas@fabula.de In-Reply-To: <20021011094150.GA3235@www> (tomas@fabula.de's message of "Fri, 11 Oct 2002 11:41:50 +0200") Original-Lines: 45 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu) 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:1528 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1528 tomas@fabula.de writes: >> It's been stated that we're going to keep all the directly linkable >> libs in the "normal place". > > Yes, I know (that's why I know I was taking risks ;-). I felt uneasy > then and still feel uneasy abut it (see below). Actually, one other thing I wanted to mention (and have already mentioned to Marius). 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? The problem is that if we don't do anything, there *will* likely be trouble if we release guile-XY, with a new major version of libguile and the system has some library or app blarg that depends on libguile-someones-foo and libguile-someone-elses-bar. If lib*foo gets upgraded on the system before lib*bar does, then blarg will likely end up being indirectly linked against 2 different major versions of libguile until a new major version of lib*bar is released. I was hoping we could avoid intermediate brokenness like that, but perhaps we can't. I guess in debian that would just mean another one of those periods during a major interpreter migration where things are very shaky. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel