[558] in athena10
Re: Could an arch/i386_deb40/bin be created in the gnu locker for Athena 10.
daemon@ATHENA.MIT.EDU (William Cattey)
Tue Oct 7 17:23:55 2008
In-Reply-To: <B0DEDCAF-637F-480E-B127-F8391679EFD1@mit.edu>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <02EEE156-50CC-4782-B7E9-068B1901F3A5@mit.edu>
Cc: gnu@mit.edu, athena10@mit.edu
Content-Transfer-Encoding: 7bit
From: William Cattey <wdc@MIT.EDU>
Date: Tue, 7 Oct 2008 17:22:19 -0400
To: Ken Raeburn <raeburn@mit.edu>
Sym-linking everything else has risks.
We know that the gtar we'd symlink to has an incompatiblity that
renders it unfit for Athena 10 nautilus use.
We know that sym-linking everything else gives functionality that
might be missing.
But we don't know what other incompatiblities there would be running
the other RHEL 4 gnu tools in a modern Ubuntu environment.
Suggestion:
Put the empty directory there immediately, and listen for requests
for missing stuff.
Build anew what is requested, and let the incremental solution evolve
into the long term one.
-Bill
----
Important: IS&T IT staff will *NEVER* ask you for your password, nor
will MIT send you email requesting your password information. Please
continue to ignore any email messages that claim to require you to
provide such information.
----
William Cattey
Linux Platform Coordinator
MIT Information Services & Technology
N42-040M, 617-253-0140, wdc@mit.edu
http://web.mit.edu/wdc/www/
On Oct 7, 2008, at 5:14 PM, Ken Raeburn wrote:
> On Oct 7, 2008, at 15:37, William Cattey wrote:
>> With people starting to use Athena 10, there is a screw case with
>> the gnu locker that needs to be remedied:
>>
>> People like me have "add gnu" in their Athena .environment file.
>
> This may be the first bug. :-)
> Nothing has changed in the gnu locker in a while; on my Linux box,
> only "recode" is dated 2007, some gpg programs dated 2006 (because
> of a security update), and everything else 2005 or older; the
> newest version of gcc is almost 7 years old. Probably very little
> of that software is current.
>
> I've long been in favor of scrapping the entire volume and
> rebuilding from scratch -- just the platforms we care about now,
> current versions of the programs, and probably omitting from Linux
> builds all the stuff likely to be local or trivially installed.
> And revisit the whole plan of using "gwhatever" names for things.
> But that means checking to see if any classes are using it, etc.,
> and a non-trivial investment of someone's time....
>
> Putting in an empty directory instead might fix your gtar problem,
> but would also mean *not* getting any programs that are less likely
> to be installed locally, like runtest or gpg. A directory of
> symlinks that doesn't include gtar may be a better short-term fix,
> and is probably the minimal behavioral change from the current
> state, if we don't want to get too invested in actually fixing
> things for real. (I think really fixing the locker is the right
> way to go, I just don't think anyone cares about it enough at this
> point to do it.)
>
> Ken
