From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.user Subject: Re: Where to install files? Date: 11 Oct 2005 15:39:05 -0400 Message-ID: References: <87y851xja3.fsf@ossau.uklinux.net> <87wtkl6oq7.fsf@zip.com.au> <873bn9t241.fsf@ossau.uklinux.net> <87y84zrj2o.fsf@ossau.uklinux.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1129059596 3792 80.91.229.2 (11 Oct 2005 19:39:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 11 Oct 2005 19:39:56 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Oct 11 21:39:47 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EPPxw-0004kw-FI for guile-user@m.gmane.org; Tue, 11 Oct 2005 21:39:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EPPxv-00054Y-RX for guile-user@m.gmane.org; Tue, 11 Oct 2005 15:39:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EPPxr-00053a-BN for guile-user@gnu.org; Tue, 11 Oct 2005 15:39:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EPPxq-00053A-Lp for guile-user@gnu.org; Tue, 11 Oct 2005 15:39:07 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EPPxq-00052x-H5 for guile-user@gnu.org; Tue, 11 Oct 2005 15:39:06 -0400 Original-Received: from [192.1.100.210] (helo=fnord.ir.bbn.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EPPxq-0006It-KU for guile-user@gnu.org; Tue, 11 Oct 2005 15:39:06 -0400 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id C008C5286; Tue, 11 Oct 2005 15:39:05 -0400 (EDT) Original-To: Neil Jerram In-Reply-To: <87y84zrj2o.fsf@ossau.uklinux.net> Original-Lines: 195 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:4834 Archived-At: Neil Jerram writes: > Greg Troxel writes: > > Yes, thanks. This is exactly what was in my mind too, but I didn't > make that clear. Glad I was helpful - was feeling redundant but posted anyway. > Basically, when I'm using a distribution (Debian in my case), I like > to do things as much as possible in the way that that distribution > designed. Agreed (for me it's NetBSD and pkgsrc). > And I would hope that distributions are broad-minded (or > control-freak!) enough to have a policy on where > non-distribution-managed stuff should go. NetBSD's take (speaking for myself, not The NetBSD Foundation - I am a NetBSD developer) is that /usr proper belongs to the base OS, and nothing else belongs there /usr/pkg belongs to pkgsrc, and only files installed/managed by pkgsrc belong there /usr/local is for people to do whatever they want with. It's not in default includes/lib search path. > Yes, exactly. And the non-distribution-managed part is foremost in my > mind right now, because the load-path issue just came up with someone > installing my guile-debugging package, which is so far only available > as a tarball. So specifically I think you mean guile installed under one prefix, probably by a packaging system some other guile-using package, e.g. guile-debugging, installed under some other prefix, but not using the packaging system. If you configure guile-debugging with the same prefix as guile, these issues become moot. Thus my restriction to the different prefix case. > > My own view is that a package configured with --prefix=/usr/foo should > > install files only under /usr/foo. This leads me with guile to want > > to extend load-path to include guile directories in other prefixes. > > On this point I think I disagree with you. I think there is value in > forcing all packages to be loaded - or at least bootstrapped - from a > known load-path that is defined by the Guile installation. To me it's not a question of value. /usr/pkg belongs to pkgsrc, and to first order other stuff (meaning unmanaged and unrecord stuff) should not be there. > Note that this doesn't _force_ all Scheme files to go under one of the > load-path locations. A big application like Gnucash could put a > bootstrap file like this in one of the standard locations ... > > (define-module (gnucash)) > > (set! %load-path (cons "/opt/gnucash" %load-path)) > > (use-modules (gnucash account) > (gnucash ui) > ...) > > ... and then all its other Scheme files under /opt/gnucash. Sure that makes sense, and another way is to have a standard, easy to follow way to register additional load-path directories with the base guile installation. > IMO this is good because everything is explicit and there is a nice > trail for the investigative free software developer to follow when > they want to understand how stuff works. good point. > > (5) location of the system init file (e.g. /etc/guile/1.6/init.scm, > > default=init.scm) > > > > Using --sysconfdir to specify this is/would be nice, and would make it > > easy to hook in a new prefix. > > I'm sure you're right, but what is it that defines sysconfdir, and > where can I read about how it behaves? It's an autoconf (configure script really) directive, or perhaps one that's commonly added, meant to specify where config files go, defaulting to $(prefix)/etc or $(prefix)/etc/PACKAGE, but commonly used to force things to /etc/PACKAGE, especially on systems where people want that. > > Guile's guile.m4 currently provides GUILE_SITE_DIR, but that feels > > wrong to me both because it doesn't handle the (2)/(3) distinction > > above, and because of the /site ending - I think of site as being for > > code put there by the local sysadmin, not for code from packages at > > all. > > > > I agree, but really we need three levels: > > pkgsrc [wrong word, but distribution-managed] > > site [managed for a group of machines] > > local [just this machine] > > Are you sure you're not a plant in the audience? Your levels idea > connects perfectly with a generalization of the scheme I described > yesterday, which occurred to me after posting: This notion of package/site/local is really just the obvious generalization of the old site/local split, once one gets over FreeBSD's misusing /usr/local for their ports system. > - At Guile configuration time, we allow the builder to specify an > arbitrary set of load path directories, each with a tag and a > description, something (semantically speaking) like this: > > '(("/usr/share/guile/1.6" > "1.6" > "Install location for Guile 1.6's own Scheme files") > > ("/usr/share/guile/site" > "site" > "Install location for site-specific Scheme files") > > ("/opt/gnome/guile" > "gnome" > "Install location for GNOME-related Scheme files") > > ("/usr/local/share/guile" > "local" > "Version-independent non-distribution-managed Scheme files") > > ("/usr/local/share/guile/1.6" > "local-1.6" > "1.6-dependent non-distribution-managed Scheme files")) > - Guile would always then initialize its %load-path to the union of > all these locations. I kind of like having several standard places within a prefix, as seen on NetBSD now: guile> %load-path ("/usr/pkg/share/guile/site" "/usr/pkg/share/guile/1.6" "/usr/pkg/share/guile" ".") Or rather, if that continues, I'd like to specify extra prefixes, with the load path being the cross product of within-prefix places and prefixes. But perhaps also single dirs. > - guile.m4 would provide a --with-guile-scheme-dir=TAG option to > ./configure, which would set GUILE_SCHEME_DIR to the location for > TAG, and a macro > > GUILE_SCHEME(default-tag) > > which a package would put in its configure.in, with default-tag > specifying the tag to use if --with-guile-scheme-dir is not > specified. > > --with-guile-scheme-dir could also specify a directory explicitly. > > Actually it may not be necessary to specify the location list above at > Guile configuration time; the list could perhaps go into init.scm, or > another init file (in sysconfdir) which is always read, even if Guile > is given a -no-init-file option. I don't follow that at all. I'd like a load-path directory, with files whose names are irrelevant but whose contets are dirs to add to the load path. This is pkg-friendly since they can be deleted and added automatically without merge/editing issues, using the fs to represent set semantics. > > It might also be nice to have a run-time method to > > > > guile-configer --addsearchprefix=/usr/bar > > > > so that someone building another package to /usr/bar can invoke this > > on the system guile to hook in the new path. > > In my view the behaviour that this allows is sufficiently covered by > the combination of > > - being able to edit init.scm (or other init file, per comment above) sure, this is a way to avoid editing, so that a makefile can invoke the 'add prefix' method which would either be refcounted or idempotent. All of this needs to be automation friendly. -- Greg Troxel _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user