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 16:37:29 -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> <87fzvc25o6.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1034368743 8772 127.0.0.1 (11 Oct 2002 20:39:03 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 11 Oct 2002 20:39:03 +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 1806Ym-0002H4-00 for ; Fri, 11 Oct 2002 22:39:00 +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 1806Xy-00017N-00; Fri, 11 Oct 2002 16:38:10 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 1806XO-000149-00 for guile-devel@gnu.org; Fri, 11 Oct 2002 16:37:34 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 1806XM-00013r-00 for guile-devel@gnu.org; Fri, 11 Oct 2002 16:37:33 -0400 Original-Received: from fnord.ir.bbn.com ([192.1.100.210]) by monty-python.gnu.org with esmtp (Exim 4.10) id 1806XM-00013n-00 for guile-devel@gnu.org; Fri, 11 Oct 2002 16:37:32 -0400 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 58DD93F19; Fri, 11 Oct 2002 16:37:30 -0400 (EDT) Original-To: Rob Browning In-Reply-To: Rob Browning's message of "Fri, 11 Oct 2002 13:26:17 -0500" Original-Lines: 57 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:1531 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1531 It's not just the compilation issue. To take your libc example, the issue in question is what happens if app blarg uses both libfoo1 and libbar1, and both of these are compiled against libc6, and then libc7 comes out. Say shortly thereafter libfoo2 comes out, compiled against libc7. If blarg is now recompiled, it'll get libfoo2 and libbar1 and hence will be indirectly linked against both libc6 and libc7 until/unless a new libfoo comes out that's linked against libc7. Is the answer "well, then blarg will just have a potential problem until libbar is updated"? I don't think we can solve everything. But here, if one rebuilds all the packages from source, libbar1 will get linked against libc7 and things will be ok. The transition period would consist of the time between when a new libguileX comes out, and when all the "add-on libs" that depend on the old version of libguile are rebuilt against the new version of guile. Actually it's only the add-on libs that are actually used by some other app or lib that also uses some other add-on lib that cause trouble, but we can't predict that. A bit of pain while guile add-ons are revved is one thing, but I would really like to avoid pain on guile-using apps, since they'll just stop. guile add-on writers are guile weenies who will not give up so easily. glib's only a good example if you consider it in a broader context. Imagine after glib 2.0 is released, libgnome-vfs has been upgraded to compile against glib 2.0 but libgnome-print has not. Where does this leave evolution when it recompiles (presuming it links against both libs)? This leaves evolution broken, I think. I think the gnome folks may create libgnome-vfs2, so that gnome2 apps can use that, and the older apps can use libgnome-vfs. As an example, orbit2 uses glib 2.0, so when switching from glib 1.2 to glib 2.0, one switches to orbit2. This would be easier if f.i. guile-gtk went under $(prefix)/share/guile/1.6 rather than $(prefix)/share/guile directly. But, I don't think such add-ons are super critical in terms of total pain and worry about guile market share loss. I agree that the problem is not completely solveable. But, I think the real question is What can guile do that minimizes pain to people who write applications using guile, and people that maintains pkgsrc/ports/deb/rpm of such programs and guile itself. (For what it's worth, I have guile 1.6 installed in /usr/projectname for a project I'm working on that uses a guile-gtk GUI to monitor things. This doesn't conflict with /usr/pkg/bin/guile, which is 1.4 for gnome etc., as long as I use the change to look up helper libs at absolute pathnames. But a different prefix isn't ok for NetBSD's pkgsrc, and I bet it's not ok for Debian either.) Greg Troxel _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel