The repository layout

The repository layout
	Reprepro setup

We want to keep packages both for Ubuntu and for Debian, and for multiple versions of each. Because all package files for all distributions in one repository are kept in a single pool (i.e. there is one pool per repository), joining Ubuntu and Debian repositories would probably create file name collisions. Reprepro (nor the Apt it communicates with) can handle such collisions. So we need separate repositories for Ubuntu and Debian, which will each contain multiple distros (e.g. 'karmic' and 'lucid' for Ubuntu).
We want to both mirror (hand picked) packages from other repositories and create packages of our own. Name collisions between these groups are not likely, so we can use components for that (e.g. 'mirrored' and 'selfmade'). Note that mirrored packages will usually (but not dy definition) be updated automatically, whereas self-made packages will mostly be uploaded.
We want to be able to have packages tagged 'experimental' and promote these to 'tested', and do that regardless of the target distribution. This can be done through pushing and pulling packages between distributions in reprepro, but it cannot move packages between components. That would mean we have to create e.g. distributions 'lucid-experimental' and 'lucid-stable'. We will be building identical versions of packages against multiple versions (e.g. build '..-01.00.01' against both 'lucid' and 'maverick'. We'll have to either include the distro against which the package is built in the version, and be very careful about which packages we copy where, or keep separate repositories for each target distro version.
We have packages that we want to share with the world, and others that we want to keep within our network. These will need different webserver access rules on their pool directories, so they will have to be different repositories.
We also have different upload security settings between distributions: most developers need upload access to some repository, but only a few should be able to directly upload to the repositories our servers download from. We can probably get away with multiple incoming directories here, and use the Uploaders field in the conf/incoming to limit the list of allowed uloaders for the official distribution(s).
We are going to want to send some packages to some machines only. There is an n-to-n relationship between machine groups and packages. Therefore a distro for each machinegroup is our solution, because packages can be copied between distros, but not components.

So we decide that these should be our repositories:

	This is just a directory
	This is also just a directory, and it will be shared through Apache as well. Separating `private` and `public` this way allows us to set different access controls on the repositories under either.
	This too is a directory, with a reprepro-made `repository` structure directly under it.
	This is a `distro` within the `repository`. Packages can be copied and moved between `distro`s.
	`main` and `mirrored` are `components` of a `distro`


“Repository, distro, component, section, area”, WTF?		Creating the repositories