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: Release now? Date: Thu, 27 Feb 2003 12:45:10 -0600 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <878yw1mukp.fsf@raven.i.defaultvalue.org> References: <87of50tdcz.fsf@raven.i.defaultvalue.org> <873cmbpyij.fsf@raven.i.defaultvalue.org> <873cm9oe9k.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 1046371669 13761 80.91.224.249 (27 Feb 2003 18:47:49 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 27 Feb 2003 18:47:49 +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 18oT4L-0003ZQ-00 for ; Thu, 27 Feb 2003 19:47:46 +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 18oT4C-0000iz-03 for guile-devel@m.gmane.org; Thu, 27 Feb 2003 13:47:36 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18oT3t-0000g1-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 13:47:17 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18oT3r-0000f5-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 13:47:16 -0500 Original-Received: from dsl093-098-016.wdc1.dsl.speakeasy.net ([66.93.98.16] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18oT1q-0000NY-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 13:45:11 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 3C0E93791; Thu, 27 Feb 2003 12:45:10 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 19163D4E23; Thu, 27 Feb 2003 12:45:10 -0600 (CST) Original-To: Greg Troxel In-Reply-To: (Greg Troxel's message of "27 Feb 2003 13:07:09 -0500") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) 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:1999 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1999 Greg Troxel writes: > There is a large transition question, though - guile 1.6 already has > libraries in a particular place. For 1.8 to have a new place is > probably fine, but this would be disruptive to those who have already > found a satisfactory solution. Hence my notion of having the > version-named midfix be optional, so Debian can use it and NetBSD can > keep using separate prefixes. Though at least for end-users compiling using guile-config, I'd hope the transition would be rather painless. > Also, we might consider having a different prefix rather than a > 'midfix', which seems awkward. With /usr/lib/guile/1.4, guile/1.4 > gets appended to $(libdir). The alternative of /usr/guile/1.4/lib, > where prefix is /usr/guile/1.4 instead of /usr, seems cleaner to me. I don't really think that's feasible, at least not as the default. At least for most of the linux distributions (and I'd guess solaris, etc.) that would be in contravention of the FHS (and predecessors), and I would guess also the LSB. > Summarizing: > > If the installed locations of guile 1.6 changes, I object because it > will cause work for people who have already coped. Hmm, but I'm only talking about changing the location of one file (a symlink) on the lib side, per library, i.e. libguile.so, which would affect packagers, but shouldn't affect anyone using guile-config. Also we're going to *have* to change the install location of the headers, i.e. /usr/include/guile/VERSION/, at least for normal autoconf style installs, i.e. FHS compliant installs since using /usr/include/libguile.h doesn't allow multiple dev versions to be installed. > I prefer the different prefix rather than a midfix. A configure > option to add a midfix seems ok, but given that we already have > --prefix, it seems like more work. I don't really think this is likely to be acceptable as a default. If you've ever seen the mass objections from *many* unix camps to attempts to violate the FHS-style /usr/lib/*, /usr/include/* approach, you know what I mean. I can understand -- there are good reasons for many of the choices made in the FHS. That doesn't mean we shouldn't have a way to support other approaches. In gnucash we had --enable-opt-style-install. I don't think I'd want to name the option that now, but it arranged for things to be /etc/gnucash/blarg by default, but to be able to be /opt/gnucash/etc/blarg when requested. It was somewhat a pain to arrange and maintain, but it can be done. > If the default behavior includes either midfixes or extra symlinks, > I object, because it is imposing what some may view as uncleanliness > on everyone because some decline to use -R. I think we may just have to agree to disagree here. From the user's perspective, the -L approach should be transparent, and from anyone else's perspective, it should be trivial to either support a --configure option that changes that default, or just let them "mv guilelibdir/* libdir/" in whatever build/install script/infrastructure they're using. Or we could possibly have an option. If what you're arguing for is in fact an "opt-style" install, then that's fine, but I think it'll have to be something that can be enabled rather than the default since it's my impression that FHS style layouts are the definite majority. > Differing prefixes and a ./configure option to symlink into another > prefix is a clean solution I think maybe I still don't have a good impression of what you're preferred solution is (and that's likely my fault) -- I'm not sure what the "prefixes" are here. Overall, I still feel like the changes I've proposed are a fairly small alteration to the current strategy, and seem to be likely to work everywhere. That's what's driving my immediate inclination. And although we may want to do it anyway, having more than one strategy, especially if they're significantly different, does increase the support burden both on the coding side, and on the end-user side. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel