[freshrpms.net] - Apt repository setup instructions

Useful files

Creating your own apt repository is probably much more simple than you'd think. The data needed by apt only represents about 1MB for an entire Red Hat Linux distribution (once compressed with bzip2, which is recommended), and with a local Red Hat Linux mirror, you can generate an apt repository within minutes. Here are a few files that will help you in doing so :

genaptrep.sh (txt) - The shell script I use to generate all my repositories (for apt 0.5.x only, old 0.3.x version here)
apt-tree.tar.gz - The directory tree needed by the genaptrep.sh script, including all the "release.*" files
Suggested naming scheme - The naming scheme I recommend for apt-rpm repositories (please read!)

Requisites

We will assume you already have the following ready and available on the server :

An http and/or ftp daemon
The "apt" rpm package installed (easiest if the server is running Red Hat Linux), grab it from ayo.freshrpms.net
A full or partial Red Hat Linux ftp mirror

Repository structure

Here is a tree to give you an idea of what's in my opinion the easiest and most user-friendly repository structure. I've adopted it after discussing with other repository administrators (see explanation and examples here) :

apt - redhat -+- 7.2 -+- en -+- i386 - os, updates, freshrpms
              |       |      |
              |       |      +- s390 - os, updates
              |       |
              |       +- ja --- i386 - os, updates
              |
              +- 8.0 --- en --- i386 - os, updates, freshrpms

I guess you get thie idea. This was inspired by Red Hat's official ftp hiererchy organization. So what we need to have is a directory structure similar to the above, for example the last line is "apt/redhat/8.0/en/i386". Then inside each "architecture" directory, we will need to have something similar to this :

i386
 |
 +-- base
 +-- RPMS.os
 +-- RPMS.updates
 +-- RPMS.freshrpms
 +-- SRPMS.os
 +-- SRPMS.updates
 +-- SRPMS.freshrpms

The main problem with the apt repository structure is that it expects all binary packages to be in one directory, and all source packages in another. While this is true with the main Red Hat Linux distribution with "redhat/linux/8.0/en/os/i386/RedHat/RPMS" and "redhat/linux/8.0/en/os/i386/SRPMS", it isn't true with the updates which do have all sources in a single "linux/updates/8.0/en/os/SRPMS" directory but binaries in various different architecture specific ones.

Before creating the repository

The "base" directory contains some manually created "release" files for each module (like "os", "freshrpms", aka "module"). These can be found in my apt tree skeleton. The program used to generate the apt metadata, "genbasedir" will create all the other needed files inside that "base" directory and expects to find all binary and sources packages for a given "foo" module under the "RPMS.foo" and "SRPMS.foo" directories, respectively, that are right next to it.
From what was said earlier, you can see that we can easily create "RPMS.os" and "SRPMS.os" as symbolic links to the directories in the original Red Hat Linux directory structure, but for the updates and similar "complex" trees, we need another solution.
The solution I use is the following : I create a real "RPMS.foo" directory, then each time just before running genbasedir, I erase all its content and run "find" to search for all binary packages in a certain place and have them all hardlinked directly inside "RPMS.foo". This is what my script does for "RPMS.updates" as well as "RPMS.freshrpms" and "SRPMS.freshrpms".

Creating the repository

Here is an example, following what we've had to deal with above. Say we have :

All Red Hat Linux 8.0 files in /var/ftp/pub/redhat/linux/8.0
An empty and ready apt directory structure in /var/apt/redhat/8.0/en/i386

All we need to run (with apt 0.5.x, not 0.3.x) is :

genbasedir --flat --bloat --bz2only /var/apt/redhat/8.0/en/i386 os updates

And this will create all the needed apt metadata in the "base" directory, assuming we've already done all the needed hardlinking for the binary packages from the updates.

Making the repository available

To make your repository available, all you need to do is either create a web virtualhost with a document root pointing to the "/var/apt" directory above, or have this "apt" directory placed somewhere else and accessible from within your ftp tree. Be careful with absolute symbolic links or ones pointing outside your tree when using ftp. Here's an example apache httpd.conf entry :

<VirtualHost *>
    ServerName ayo.freshrpms.net
    DocumentRoot /var/apt
    <Directory /var/apt>
        Options +Indexes
    </Directory>
    ErrorLog logs/ayo.freshrpms.net-error_log
    CustomLog logs/ayo.freshrpms.net-access_log combined
</VirtualHost>

Once this is done, clients can use the repository by putting these entries in their /etc/apt/sources.list file :

rpm http://ayo.freshrpms.net redhat/8.0/en/i386 os updates
rpm-src http://ayo.freshrpms.net redhat/8.0/en/i386 os updates

I recommend using http as it gives better responsiveness since there is no login needed. It's also easier to generate statistics, but harder to restrict the number of simultaneous downloads.