[33] in athena10
Athena 10 project infrastructure
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Jan 9 01:56:46 2008
Date: Wed, 9 Jan 2008 01:56:34 -0500
Message-Id: <200801090656.m096uYWB001965@equal-rites.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: athena10@MIT.EDU
Debathena has four pieces of project infrastructure, depending on how
you count:
1. The package source and build directories under
/mit/debathena/packages, and the scripts in /mit/debathena/bin
and /mit/debathena/machines/awesome-build-server.
2. The apt repository in /mit/debathena/apt (and the beta
repository, which apparently doesn't get used much, and I'm not
clear on how it's maintained).
3. The build machine debuild.mit.edu.
4. The HTTP server debathena.mit.edu which serves the apt repository
from AFS and contains documentation. This is actually a
scripts.mit.edu vhost, so /mit/debathena/web_scripts is pretty
much the entirety of this piece.
I am, obviously, in the process of replacing (1) with the debathena
subdir of the Athena 10 trunk. The scripts and current procedures
make some assumptions about the package build area and will need to be
adjusted.
For (2) I assume we will want to create our own separate apt
repository during the development of Athena 10. Once we're closer to
shipping we can discuss whether to have a single apt repository and
where it should live in AFS. The daupload and dadch scripts make
assumptions about the location of the apt repository but that should
be easy to ajdust--just add an environment variable override or
something similar.
For (3) I've asked our sysadmins to reinstall snuggle (the off-cycle
Linux build machine) with gutsy. It has a small disk (40GB) because
it's an old machine, but I think that will serve for the moment. The
Debathena scripts make no assumptions about the name of the build
server or that there's only one build server, so no adjustment is
necessary on that front.
I haven't come to any firm conclusions about what I want (4) to look
like during development or production.
