[2025] in SIPB_Linux_Development
Re: How about a new RH-A release for next year?
daemon@ATHENA.MIT.EDU (Derek Atkins)
Mon Jun 1 10:21:54 1998
To: amu@MIT.EDU (Aaron M. Ucko)
Cc: Emil Sit <sit@MIT.EDU>, linux-dev@MIT.EDU
From: Derek Atkins <warlord@MIT.EDU>
Date: 01 Jun 1998 10:21:09 -0400
In-Reply-To: amu@MIT.EDU's message of 31 May 1998 13:54:54 -0500
The PAM stuff I did can be found in
/mit/sipb/project/sipb-athena/src/pam. I didn't get very far, I'm
sorry to say. I also didn't do any work to integrate into the new
Athena Login Library. It's in the source-sipb code, so if you use
that (see below) you'll get it. It wont give you PAM, however you
might be able to start with my old cruft and build a PAM module.
I've got a few pending patches for Linux-AFS, mostly coming from CMU.
Jeff Hutzelman has been great at feeding me patches :) I'll go talk to
him about integration. This might solve some of the AFS problems (but
who knows if it will solve all of them?)
I've not seen the 5.x install, so I don't know how much of my work
will port. If nothing else you can run a "cvs diff" against the base
redhat sources to see the changes I've made.
As for the source tree, I agree that we should move to using
source-sipb, and let sipb-athena die. I think most stuff there
_should_ work on Linux, even with GLIBC. It will take some time to do
the port, but a coordinated effort can quickly run through the tree.
I'd recommend you make a file containing all the packages, and as
someone tries to port a particular package you mark your name in the
file. Then mark it as "done" when you check-in working code.
For auto-updates I think you'd need to install all of Linux into a
locker somewhere (/os) so you can update from it. Either that or
automate the update.pl script.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH
warlord@MIT.EDU PGP key available
