[5858] in Release_7.7_team
Proposed repository plan for Athena 10 work
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Oct 10 00:39:44 2007
Date: Wed, 10 Oct 2007 00:39:06 -0400
Message-Id: <200710100439.l9A4d6ob018222@equal-rites.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
X-Spam-Flag: NO
X-Spam-Score: 0.00
I discussed most of this at the release team meeting already. The
plan is:
1. We get ourselves an "athena" repository on svn.mit.edu and import
the current CVS repository into it (trunk only for cleanliness).
The CVS repository becomes, effectively, a 9.4 branch. We arrange
for an automated daemon to be able to access the athena repository
so that we can create a mirror and a checkout in AFS.
2. The athena hierarchy stays mostly as-is, although a few individual
packages might go away or move. Also, some packages in there will
stop getting built (like Zephyr and Hesiod) but will remain in the
source tree since we are the upstream maintainers.
3. The third hierarchy becomes very small, but probably doesn't go
away entirely. Little stuff like third/lam stays where it is, and
hard stuff like third/lprng might stay where it is just because it
might become too hard to get away from building it. But we get rid
of as much as we can, probably over 90% of what's in there.
4. The packs hierarchy goes away.
5. A new hierarchy "ubuntu" appears, with the following general
structure:
5a. ubuntu/build contains build scripts.
5b. ubuntu/athpkg contains files with names like "discuss" which
correspond to package names for software under athena/ and third/.
Much like packs/build/rpm/specs.
Note: currently, a number of athena/ packages pull in files from
packs/config or packs/maint via scripts in packs/build/rpm/prep.
I'd like to get away from that. The problem will mostly solve
itself as we get rid of stuff in third/, but in some cases we will
need to either move the config file into the athena source tree or
create a new package with a name like athena-athinfod-config. The
latter approach is cleaner since it mirrors how we will be
separating Athena configurations for native software (like gdm)
from the software itself.
5c. ubuntu/pkg contains directories with names like "gdm-config", each
containing the package description files and package contents for
athena-gdm-config. For instance, in the case of gdm-config, the
directory would contain the modified gdm.conf, the desktop files
for the login sessions, and maybe the Xsession script.
5d. ubuntu/native contains materials for native packages like gconf2
which we will need to modify. I'm thinking the substructure of
each directory might look like:
ubuntu/native/gconf2/dpkg
ubuntu/native/gconf2/ubuntu
ubuntu/native/gconf2/athena
where "dpkg" is the raw package materials, "ubuntu" is the
prepared source tree, and "athena" is the modified source tree (a
copy of the ubuntu directory). The build script would work by
diffing "athena" against "ubuntu", adding the result as a patch to
"dpkg", and doing a normal Debian package build.
Details may change as I learn more about how dpkg works.
