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 13:26:17 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <87fzvc25o6.fsf@raven.i.defaultvalue.org> 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 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1034360833 6292 127.0.0.1 (11 Oct 2002 18:27:13 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 11 Oct 2002 18:27:13 +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 1804VC-0001d3-00 for ; Fri, 11 Oct 2002 20:27: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 1804VF-0008Hz-00; Fri, 11 Oct 2002 14:27:13 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 1804UP-0008Cm-00 for guile-devel@gnu.org; Fri, 11 Oct 2002 14:26:21 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 1804UN-0008CL-00 for guile-devel@gnu.org; Fri, 11 Oct 2002 14:26:20 -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 1804UM-0008C8-00 for guile-devel@gnu.org; Fri, 11 Oct 2002 14:26:18 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 7B76E17EA; Fri, 11 Oct 2002 13:26:17 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 23FAA2F64; Fri, 11 Oct 2002 13:26:17 -0500 (CDT) Original-To: Greg Troxel In-Reply-To: (Greg Troxel's message of "11 Oct 2002 13:10:03 -0400") Original-Lines: 80 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:1530 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1530 Greg Troxel writes: > 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. 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 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. Being able to have both installed would keep us from stalling all the developers during the transition period, but it won't really help with the problem above. I believe the libguileX-somelib naming convention would fix the problem, but as mentioned, only for guile. It wouldn't address the broader unix inter-lib version problem, and so perhaps we should just suffer along with everyone else through the (hopefully brief) transition periods. 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. Of course, if it takes a long time for add-on libs that are commonly used in conjunction with other guile libs to get updated, then the "transition period" could be long. For example, if there were a libguile-gobject that languished, that could really hold things up. > I'm less worried about guile-gtk, since that tends to get dynamically > loaded from a scheme script. Right. Guile-gtk's not really a good example, but an external libguile-gobject that you could call from other C libs/programs would be a good example, say one that provided scm_gobject_create_obj () or whatever. > 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. 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)? (I'm not sure this particular case would be a problem, but it's an example of the broader issue...) > Sorry for rambling on again... Not at all. I appreciate the effort. This is too complicated for me to even want to try to figure out on my own. -- 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