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 09:25:41 -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> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1046356154 29843 80.91.224.249 (27 Feb 2003 14:29:14 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 27 Feb 2003 14:29:14 +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 18oP1W-0007h4-00 for ; Thu, 27 Feb 2003 15:28:35 +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 18oP08-0002J2-00 for guile-devel@m.gmane.org; Thu, 27 Feb 2003 09:27:08 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18oOzp-0002FT-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 09:26:49 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18oOzM-0001zq-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 09:26:21 -0500 Original-Received: from fnord.ir.bbn.com ([192.1.100.210]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18oOyo-0001YK-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 09:25:46 -0500 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 9342686E; Thu, 27 Feb 2003 09:25:41 -0500 (EST) Original-To: Rob Browning In-Reply-To: <873cmbpyij.fsf@raven.i.defaultvalue.org> Original-Lines: 83 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:1990 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1990 What do you think about my other suggestion? i.e. - put libguile.so.*, etc. in /usr/lib (i.e. ${libdir}) - put the libguile.so development symlinks (i.e. the ones -l uses) in /usr/lib/guile/VERSION - put the headers in /usr/include/guile/VERSION - require the use of guile-config and arrange for guile-config to spit out -I/usr/include/guile/VERSION and -L/usr/lib/guile/VERSION when appropriate I suppose /usr/share/guile/VERSION already exists, and /usr/bin/guile (and guile-config) can be named with versions as well. It strikes me as inelegant to link against a library in one place and then expect ld.so to find it someplace else. I think your plan is workable, but in my view the 'put the other version in a different prefix' plan feels cleaner. But, it requires rpath or DT_RPATH, which seems to be ok in most places except debian. (It is certainly heavily used in NetBSD, which puts third party stuff in /usr/pkg and does not have /usr/pkg/lib in the default search path.) At this point, for NetBSD I'm happy with NetBSD's current solution. I would be perfectly content for your plan to be a ./configure-time option, as it seems to be among the best suggestions to date for a no-rpath environment. I suppose if guile-config/pkg-config spits out the right -I and -L paths then this would be ok for other systems. But having a library compile-linked from one place and run-linked from another seems to be asking for trouble, and I would prefer not to see that complexity and associated unintended consequences imposed on everyone because Debian chooses not to use -rpath. (I realize libtool does this for running uninstalled code, but I think that's different.) All that said, I have to ask myself: what's wrong with putting the guile version number in the soname and all other files, glib-style? This makes names bigger, but seems less likely to create hard-to-find bugs. This could also be a ./configure-time option, perhaps used only when installing a secondary version. Or, on systems that say dependency libs have to be updateable without reinstalling dependent programs, this should perhaps be used all the time. In December you wrote to debian-devel: One solution might be to just require all guile add-on libs to be placed in /usr/lib/guile/X.Y and then require the use of -rpath or similar, but I suspect that's a non-starter. Another might be to make it guile policy to encode the name of the guile version into the lib name, i.e. libguile1.6-gwrap-glib, but that's pretty ugly and it's not very scalable. I think it is important to keep separate notions of scalability imposed by such a naming scheme and the scalability of the underlying reality. Here, the reality is messy, and the naming scheme means that various combinations can coexist peacefully. It enables having 12 versions at once, but that is the underlying reality, unless some are prohibited. Of course, not having a mechanism has the effect of prohibiting this. Why wouldn't such a rationale also justify libguile1.6-gwrap-glib1.2-crypt1-c6,so? It justifies only libguile1.6-gwrap-glib1.2. The key point that I've been trying to get across (which our discussion has clarified in my mind) is that there are two separate kinds of version changes. One is the traditional shlib major version bump. But generally, that merely means programs must recompile, and make an occasional small change. The other kind is that interfaces have changed so significantly that it isn't reasonable to tell people "Just recompile and fix your program. From now on only the new version is available and if you can't cope you are just going to lose." The "just cope" is what happens when libc has a major version change. The work to cope is not too bad, and it isn't viewed as reasonable to provide a way around it. I'm hoping that guile 1.6->1.8 will be like this. Other changes, like glib 1.2 to 2.0, are so far reaching that the maintainers feel the need to support having them both installed. Part of the reality is that the more important a library is, the more effort the library can impose on users with changes. With guile, we want people to use guile more than they feel the need, so the amount of pain we can impose is small. Greg Troxel _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel