Changes between Version 1 and Version 2 of APTRepositoryManagement


Ignore:
Timestamp:
07/06/15 08:04:11 (6 years ago)
Author:
jdreed
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • APTRepositoryManagement

    v1 v2  
    11= Manual APT repository management = 
    22 
    3 talk about dareprepro and stuff 
     3The 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 
     7A `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 
     18The repository has 4 components:  
     19* `debathena` 
     20* `debathena-system` 
     21* `debathena-config` 
     22* `debathena-manual-config` 
     23* `openafs` 
     24 
     25In 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 
     29Debathena creates a one suite per codename we support (e.g. `precise`, `lucid`, etc). 
     30 
     31However, we also create variants of each suite, adopting a hybrid of former Athena naming schemes and current Ubuntu naming schemes 
     32 
     33For 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 
     38Typically, 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 
     40There 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 
     45The 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 
     47Manual 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 
     49Consult the `reprepro` manpage here: [http://mirrorer.alioth.debian.org/reprepro.1.html]