[3] in athena10
Athena 10 and Debathena
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Nov 30 02:52:34 2007
Date: Fri, 30 Nov 2007 02:52:27 -0500
Message-Id: <200711300752.lAU7qRIM014218@equal-rites.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: athena10@MIT.EDU
On Wednesday I met with tabbott and hartmans to discuss the
relationship between Athena 10 and Debathena. Here is the high-level
background:
* Debathena is an existing product of SIPB, which uses Athena
sources and original materials to provide Athena-like
functionality for seven different versions of Debian and Ubuntu.
Its highest-profile deployment is probably the linux@mit.edu
dialup (aka linerva) but it is also used by about 200 other
machines by their count, including a cluster in the 6.001 lab.
Debathena does not include all of the monitoring and
self-maintenance features of the Athena release and may be missing
some GNOME fixes for AFS homedirs, but does include the core
features and most of the command-line utilities. The Debathena
developers are tabbott and andersk.
* Athena 10 is a planned project to move Athena to Ubuntu 8.04
(Hardy Heron) and reduce the maintenance burden of the release by
leveraging more native platform components. The plan I had
developed for this project is at
http://web.mit.edu/release/www/athena10. The approach I had been
planning to take was to use Debathena liberally as a reference,
but to produce a wholly separate product.
* tabbott met with me based on some concerns about the inefficiency
arising from IS&T providing an officially supported set of Athena
packages for one specific release of Ubuntu, and leaving it to
others to provide similar packages for other Debian and Ubuntu
versions. In particular, Debathena has evidence (based on package
repository statistics) that private machine owners do not stick to
Ubuntu long-term support releases, and would be interested in
packages for whatever Ubuntu release follows 8.04 even if Athena
clusters don't adopt it.
* Sam suggested that ISDA should consider developing Athena 10 as a
collaboration with Debathena, such that Athena 10 is a successor
to Debathena as well as Athena 9.4. The Athena 10 infrastructure
would contain enough bits to produce packages for all supported
Debian and Ubuntu versions, but ISDA would only take
responsibility for resolving issues on Ubuntu 8.04. I initially
had reservations about this idea, but have come around somewhat.
From Debathena's perspective, this collaboration would mean
shifting from treating Athena sources as an upstream provider to
becoming co-maintainers of the upstream source.
Some low-level consequences of such a collaboration, if it should fly:
* The package names would likely be named debathena-* instead of
athena-* as I had envisioned, since a package name migration is a
pain. Not a big deal.
* Debathena does not currently use a version control repository.
They're not throwing away any information--the source packages
contain the full history--but ISDA has a policy of keeping
everything in Subversion repositories on svn.mit.edu. Debathena
developers would get commit access to this repository as part of
the collaboration.
* I had originally envisioned keeping the Debian package goo for
Athena sources in a separate location (ubuntu/athpkg in the
repository) to preserve the platform-independent nature of the
Athena sources. It might be convenient to plunk debian
directories directly into the Athena source directories. That way
you could check out athena/bin/delete (or whatever), use dch -i
directly from the checkout to edit the changelog after making a
change, and build the package directly from the checkout (no need
for a package build script like I wrote over the past couple of
weeks).
* Athena source directories do not currently contain generated or
stock autoconf goo (configure, config.sub, config.guess,
mkinstalldirs, install-sh, ltmain.sh, libtool.m4) or the Athena
aclocal.m4 file. If we want to be able to build binary packages
directly from checkouts, we'll need to do something about that.
There may need to be a preparation script which turns a checkout
into the actual source package--for aclocal.m4 if nothing else.
* It's pretty easy to use the same source package to build binaries
for multiple Debian and Ubuntu releases--just don't rely on any
recent features of debhelper or CDBS (I would assume). Life gets
harder for the places we need to modify upstream packages such as
bash and tcsh, because there is potentially a different source
package for each release. Debathena currently has three such
instances, and they generally handle them by using a script which
processes the source package.
* Cosmetic issue: I like the idea of treating Athena 10 packages as
"Debian original packages", i.e. with no orig tarball. I think
Sam agrees with me, tabbott doesn't have a strong opinion, and
andersk disagrees. It's a fine point in any event.
* Cosmetic issue: Debathena uses package version numbers like
"9.4.0-0debathena1~ubuntu7.04" to indicate which Debian or Ubuntu
release a binary package was built on, and stores all of the
resulting packages in one repository. I like the idea of using
much more terse package versions like "10.0.0" and creating
separate repositories for each Debian or Ubuntu release. tabbott
disagrees with me, and I may just lack the necessary background to
know why having one repository is best.
