From: Greg Troxel <gdt@ir.bbn.com>
To: Jon Wilson <jsw@wilsonjc.us>
Cc: guile-user@gnu.org
Subject: Re: Autoconf test for site scheme files
Date: Sun, 12 Aug 2007 07:43:38 -0400 [thread overview]
Message-ID: <rmiabsxm105.fsf@fnord.ir.bbn.com> (raw)
In-Reply-To: <46BE8C1B.8090308@wilsonjc.us> (Jon Wilson's message of "Sun, 12 Aug 2007 00:27:07 -0400")
Jon Wilson <jsw@wilsonjc.us> writes:
> Using ubuntu, apt installs packages under /usr. When I find something
> that either isn't up to date enough or doesn't exist in the ubuntu
> repos, I build it from source. In that case, I either install to /opt
> or to /usr/local. Sometimes this includes packages which want to
> install guile modules (currently, it includes guile!). I try to keep
> /usr untouched except by apt, but it does make sense to have these
> modules in a `site' directory.
>
> For instance, I have guile-lib installed from the ubuntu package to
> /usr/share/guile/site, and I have guile-gdbm installed to
> /usr/local/share/guile/site. I think this constitutes a pragmatic
> (although perhaps not good?) reason to have two site dirs.
Sure, this makes sense - the problem is that people use the word site
for different things. Long ago, on a 4.2 system, we had /usr/site and
/usr/local. /usr/site was for the group of 15 machines (a lot of money
back then!), all synced from one. /usr/local was really for the machine.
Note that /usr/local isn't necessarily a good choice because on FreeBSD
the packaging system puts things there. (I'm not saying it's a problem
in your case.)
In the present case, you're using prefix to separate package-managed and
local software. I agree; I have base system (NetBSD) in /usr,
pkgsrc-managed packages in /usr/pkg and my own stuf f in /usr/y0.
I think it's perfectly sensible to have things in various prefixes for
separation by maintenance method. What's needed is an /etc/prefixes
file, or something, that many programs can read to construct their
default search path. Unfortunately this is messier because different
systems have different hierarchy rules (e.g., /usr/pkg/info vs
/usr/local/share/info), but in the guile case it's ok.
So, what do you do to get the various code loaded? symlink stuff in
/opt into /usr? Adjust load-path?
Also, I'm curious why you don't just update the source package yourself
and build it. In pkgsrc I often just change version numbers in
makefiles and build. But I have commit privs, so it isn't wasted work,
and pkgsrc has differet stability rules.
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
prev parent reply other threads:[~2007-08-12 11:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-07 15:42 Autoconf test for site scheme files Mike Gran
2007-08-07 16:35 ` Greg Troxel
2007-08-07 16:52 ` Mike Gran
2007-08-08 7:20 ` Ludovic Courtès
2007-08-08 15:03 ` Mike Gran
2007-08-12 4:27 ` Jon Wilson
2007-08-12 11:43 ` Greg Troxel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=rmiabsxm105.fsf@fnord.ir.bbn.com \
--to=gdt@ir.bbn.com \
--cc=guile-user@gnu.org \
--cc=jsw@wilsonjc.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).