| 3 | | talk about dareprepro and stuff |
| | 3 | 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. |
| | 4 | |
| | 5 | == APT Configuration == |
| | 6 | |
| | 7 | A `souces.list` entry has (usually) the following format: |
| | 8 | |
| | 9 | {{{ |
| | 10 | <type> <url> <codename> <component> [<component2> ... <componentN>] |
| | 11 | }}} |
| | 12 | |
| | 13 | * `<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 |
| | 14 | * `<url>` is the URL to the base of the repository (which must contain `dists` and `pool` subdirs) |
| | 15 | * `<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`). |
| | 16 | * `<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. |
| | 17 | |
| | 18 | The repository has 4 components: |
| | 19 | * `debathena` |
| | 20 | * `debathena-system` |
| | 21 | * `debathena-config` |
| | 22 | * `debathena-manual-config` |
| | 23 | * `openafs` |
| | 24 | |
| | 25 | 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. |
| | 26 | |
| | 27 | === Suites === |
| | 28 | |
| | 29 | Debathena creates a one suite per codename we support (e.g. `precise`, `lucid`, etc). |
| | 30 | |
| | 31 | However, we also create variants of each suite, adopting a hybrid of former Athena naming schemes and current Ubuntu naming schemes |
| | 32 | |
| | 33 | For each suite, there is: |
| | 34 | * `suitename-proposed` - also known as "beta". Some machines in the field pull from this. |
| | 35 | * `suitename-development` - also known as "alpha". No public machines should pull from this -- this is really for developers to test things. |
| | 36 | * `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). |
| | 37 | |
| | 38 | 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. |
| | 39 | |
| | 40 | There is also: |
| | 41 | * `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` |
| | 42 | |
| | 43 | === Managing the repository === |
| | 44 | |
| | 45 | 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. |
| | 46 | |
| | 47 | 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`. |
| | 48 | |
| | 49 | Consult the `reprepro` manpage here: [http://mirrorer.alioth.debian.org/reprepro.1.html] |
