[1341] in athena10
Apt repository layout
daemon@ATHENA.MIT.EDU (Evan Broder)
Fri Mar 6 19:36:19 2009
Message-ID: <49B1C016.2090206@mit.edu>
Date: Fri, 06 Mar 2009 19:30:14 -0500
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: debathena@mit.edu
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
I know I've discussed this with a couple of SIPB developers in the past,
but I don't think I've ever actually sent mail about it, so...here goes.
First, a primer on terminology:
Consider a typical line from a sources.list:
deb http://debathena.mit.edu/apt hardy debathena debathena-config \
debathena-system openafs
- The URL is the "repository"
- "hardy" is the "release"
- "debathena", "debathena-config", "debathena-system", and "openafs"
are "components"
- Each line has a single repository, a single release, and 1 or more
components
And there's your primer. That was easy, right?
I'd like to eliminate what is currently the beta *repository* (in
/mit/debathena/apt-beta) and instead have a beta *release*. It's
annoying currently to test things using the beta repository. Few people
have it in their sources.list, and more importantly, you can't move
packages between *repositories*. You can, however, move packages between
*releases*.
Specifically, I'd like to create 3 different releases in our repository
for each Debian/Ubuntu release we support:
- intrepid
- intrepid-proposed
- intrepid-development
Approaching these in reverse order, "intrepid-development" would not be
something that anybody but a Debathena developer would want turned on.
It would be for packages under active development, and may not have any
guarantees about versioning consistency or anything useful like that. It
can generally be used when a developer wants to actually test something
in an apt repo, as opposed to testing with `dpkg -i`
"intrepid-proposed" are changes that are scheduled to be incorporated
into the production release. Think of it as roughly equivalent to
machines being "in the dev cell" in Athena 9. We should encourage
clueful people to turn this on, and only push updates that we don't
think will horribly break their system. This would take the place of the
beta repository.
"intrepid" would, of course, be the default "production" release.
Assuming I can manage to wrap my head around the necessary Makefiles,
I'm hoping to create the separate releases this weekend, and maybe write
some shell scripts to make migrating packages between releases a little
easier.
Once the releases exist, there's some dev work to be done to take full
advantage of them:
- debathena-auto-update should add or remove the -proposed release
based on clusterinfo.
We should come up with some Moira clusterinfo settings to indicate that
a machine should be using -proposed. We could possibly match the current
sysprefix clusterinfo setting, but having a setting of our own seems
like it might be a better long-term option.
- The autodebathenificator should upload packages to -proposed (and
then we can finally turn it on!)
- We should have a cron job to notify us every so often that something
has been sitting in -proposed for more than a day or two, because that
may mean somebody forgot to migrate it to production
I'm a bit on the fence in terms of how to use the new layout once we
have it in place, though. I do think that at some point we should shift
our policy some in terms of when we ship updates. Currently updates
undergo anywhere from no testing to minimal testing to extensive testing
depending on the update and the developer. Sometimes they're tested on
multiple platforms, sometimes just the developer's.
On the one hand, I think that requiring all updates to go through
-proposed can lead to a more stable release. Previously, I had planned
to suggest that we let any non-emergency updates sit in -proposed for at
least 24 hours before going into production.
However, Debathena is only moderately ready for the cluster right now. I
think one of the most important things we can do to keep people from
perceiving Cluster Debathena as not being ready is responding to user
issues as quickly as we can, and requiring that packages sit for 24
hours is not a good way to create an image of being highly reactive.
So I think that, for now, we should leave this up to developer
discretion, but in the case of non-user-requested and non-emergency
updates, we should consider passing them through -proposed for a while
to give a wider variety of users a chance to test the changes.
- Evan
