What is the structure of an Ubuntu repository?

Question

How are the files in an Ubuntu repository organized? What are the important files in a repository? What happens when a repository becomes inconsistent, broken or is being synced?

Answer 1

Joao answered the second half of my question, so I investigated the first half on my own. At the root level, there are four directories and one file.

root
| -- dists
| -- pool
| -- indices
| -- project
| -- ls-lr.gz

(Also in my college repo, only the first two entries were there. So the last 3 seem to be non-essential to the functioning of the repo.)

The file ls-lr.gz contains the output of the ls -lr command as run on the repository root directory.

The dists directory seems to contain most of the metadata, including all the packages.gz file (which contains a list of packages) and Release.gpg/Release which signs the package. (Thanks to Joao for the info)

The pool directory contains the actual .deb files. The organization is /pool/[section]/[letter]/[group]/packagename.deb. Thus the actual location of the python-subversion package is /pool/main/s/subversion/python-subversion_1.3.2-3ubuntu2%7edapper1_amd64.deb, because subversion is the group of the python-subversion package, and s is the first letter of subversion.

The projects directory seems to contain a few files detailing how the mirror was synced to the original repo.

The indices directory contains many files, most of them empty. The non-empty files seem to supply some extra metadata for packages.

Answer 2

According to the deb line on your apt source, apt will fetch:

• http://archive.ubuntu.com/ubuntu/dists/release/Release
• http://archive.ubuntu.com/ubuntu/dists/release/Release.gpg
• http://archive.ubuntu.com/ubuntu/dists/maverick/COMPONENT/binary-ARCH/Packages.gz

It validates if the Release.gpg is a valid signature for the Release file, and if the Packages.gz contents matches the integrity checksum present on the Release file. If there is a mismatch, a repository signature integrity failure is reported.

The package file name for the requested package is determined from the previously retrieved Packages.gz contents. It is downloaded, and its content checksum must match the Packages.gz checksum content or an integrity failure is reported.

Your last question is not about the mirror structure per se, it is about the mirror synchronization, which depends on the mirroring process. It is possible to synchronize using a temporary location without breaking the archive integrity during synch. I am not sure if all Ubuntu mirrors do that.