wiki:APTRepositoryManagement

Version 2 (modified by jdreed, 6 years ago) (diff)

--

Manual APT repository management

The Debathena APT repository is served from debathena.mit.edu/apt. The docroot is /mit/debathena/web_scripts/apt, and as the name implies, it is served via Scripts.mit.edu.

APT Configuration

A souces.list entry has (usually) the following format:

<type> <url> <codename> <component> [<component2> ... <componentN>]
  • <type> is one of deb (for binary packages) or deb-src (for source packages). Most repos have two entries -- one for binary, one for source
  • <url> is the URL to the base of the repository (which must contain dists and pool subdirs)
  • <codename> (also called suite, also called release) is the codename for the distribution (e.g. lucid, precise, wheezy, jessie) or, in Debian, an alias (unstable, testing).
  • <component> is a part of the repository, that identifies a subset of packages. In Ubuntu, this is something like main, universe, multiverse. In Debian, this is something like main, nonfree, etc). Multiple components can be specified on a single line, or you can have multiple line entries, one per component. It is an error to list the same (type, url, codename, component) tuple more than once in the entire APT sources for a machine.

The repository has 4 components:

  • debathena
  • debathena-system
  • debathena-config
  • debathena-manual-config
  • openafs

In most sources.list snippets, only the first 3 are used. The installer only configures the first 3. debathena-manual-config is for people who want to use the manual-config packges, and openafs was used for auto-building kernel modules for OpenAFS for all distros we supported. As of Lucid (10.04), when DKMS became widely available, we stopped doing that. Older machines may still have the openafs component listed, but it can be ignored, and will be empty on modern distros.

Suites

Debathena creates a one suite per codename we support (e.g. precise, lucid, etc).

However, we also create variants of each suite, adopting a hybrid of former Athena naming schemes and current Ubuntu naming schemes

For each suite, there is:

  • suitename-proposed - also known as "beta". Some machines in the field pull from this.
  • suitename-development - also known as "alpha". No public machines should pull from this -- this is really for developers to test things.
  • suitename-bleeding - The "bleeding-edge" repository. Really, this only ever used to test weird APT upgrade paths and things like this. Nobody but core developers should even know about this. This repository does NOT guarantee version integrity. (That is, the package defined as version 1.0 may in fact change its contents (and thus checksum) at any time).

Typically, we manage every suite simultaneously, until we take a suite offline. That is, if we support precise, trusty, and wheezy, then we move packages from alpha to beta for all suites simultaneously. Our suites are typically referred to merely by their suffix. That is, when talking about -development, you're talking about suitename-development for all the suitenames we support.

There is also:

  • suitename-staging - this is used when bringing a new suite online (e.g. when Ubuntu releases a new version), to allow packages to sit here until the release is "complete". They are then bulk-moved to -development

Managing the repository

The vast majority of repo management is done as part of the build process (which builds new packages into -development) and using damove to move things between suites.

Manual management can be done with dareprepro. This is a thin wrapper around reprepro, which is an upstream tool. The purpose of the wrapper is to set the repository path, and some other Debathena-specific options, but other than that, it behaves identically to reprepro.

Consult the reprepro manpage here:  http://mirrorer.alioth.debian.org/reprepro.1.html