[572] in athena10
Re: Could an arch/i386_deb40/bin be created in the gnu locker for
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Thu Oct 16 11:35:21 2008
Date: Thu, 16 Oct 2008 11:34:35 -0400 (EDT)
From: Geoffrey Thomas <geofft@MIT.EDU>
To: Ken Raeburn <raeburn@mit.edu>, William D Cattey <wdc@mit.edu>
cc: gnu@mit.edu, athena10@mit.edu
In-Reply-To: <967133FC-8545-4842-89B9-62C137F14D7F@mit.edu>
Message-ID: <alpine.DEB.2.00.0810161122350.29207@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
[I meant to send a message like this a few days ago, but I apparently
didn't. Sorry.]
I don't think gtar is the only command that people will be using like
this. For example, the 6.828 grade.sh script uses gmake, which exists in
the GNU locker but is not installed on Debian/Ubuntu. (Linerva has a local
/usr/bin/gmake -> make symlink after I bugged the Linerva maintainers
about this.) There are two options that seem cleaner to me:
1) Athena 10 / Debathena makes sure that all files in /mit/gnu/bin exist
in /usr/bin (or /bin or whatever), usually by installing software, but
also by creating symlinks from gfoo to foo, etc. (Software with explicit
version numbers can be ignored.) The i386_rhel4 sysname remains as the
compatibility sysname for Athena. This way the local installation always
shadows an added gnu locker, but athrun or add -f can still be used to
access the gnu locker. You shouldn't put add -f gnu in your dotfiles, but
that's basically true on RHEL Athena 9 too.
2) /mit/gnu/arch/i386_deb40/bin/* and g* are symlinks to /usr/bin/*.
Usually scripts that athrun the gnu locker, on Athena 10, actually want
the local copy.
The difference is basically whether the people/scripts referencing the gnu
locker with athrun/add -f actually want the gnu locker, or not.
--
Geoffrey Thomas
geofft@mit.edu
On Thu, 16 Oct 2008, Ken Raeburn wrote:
> Bill and I talked about this a little yesterday. What came out of it is:
>
> * No one else seems to care. Not that I care all that much either...
>
> * This is GNU software we're supplying, and Ubuntu is loaded with lots of GNU
> software already, so what's the point?
>
> * Apparently the recommended approach for third-party software lockers for
> Athena 10 will be to create empty directories in AFS and recommend local
> installation of the software.
>
> Then I brought it up on Zephyr (class sipb), and a bunch of people complained
> that "athrun gnu gtar" is used in scripts. So, maybe a few people do care.
>
> So I've created an arch/i386_deb40 (not a new volume, since it's so small)
> which will have a symlink for "gtar" and the following README file. If a few
> more symlinks are needed for "athrun" (or "attachandrun") invocations, that's
> probably okay, but I think we should try to keep the content to a minimum,
> and tell people "install it locally" (or get it to be part of the base
> athena10 system).
>
> Ken
>
> ------- README
>
> The recommended approach for providing free or open-source software
> under Athena 10 is likely to be to use local installation rather than
> locker-provided software. (http://diswww.mit.edu/menelaus/athena10/569,
> https://wikis.mit.edu/confluence/x/2gM0AQ) For your own private
> workstation, it's probably the right thing to do in any case. Public
> Athena 10 machines may be a little trickier, but that issue can be
> explored while Athena 10 is in development.
>
> And as Athena 10 is going to be based on Ubuntu, which is based largely
> on GNU software, it seems silly to try providing more copies of the same
> software in a locker. (The same is true of Debathena.) Besides, in
> recent years the locker has grown stagnant, so anything we provide here
> is likely to eventually become out of date.
>
> So, for now at least, we are not providing the gnu locker software for
> Athena 10 (or Debathena) systems.
>
> One exception: A number of scripts around Athena use "athrun gnu gtar"
> to explicitly get the GNU version of tar (e.g., even on Solaris). Since
> GNU tar is part of the base OS for Athena 10, a symbolic link will keep
> the explicit pathname reference working, without our needing to keep
> current with the latest release.
>
