Differences between revisions 89 and 90
Revision 89 as of 2015-05-07 14:43:36
Size: 16419
Editor: PaulWise
Comment: mini-dak updates
Revision 90 as of 2015-05-08 19:28:12
Size: 16324
Comment: this link is dead
Deletions are marked like this. Additions are marked like this.
Line 165: Line 165:
  * [[http://debian.wgdd.de/debhowtos/howto-aptrep.de.html|debarchiver how-to (in German)]].

Translation(s): 한국어(Korean)

This document summarizes the process of setting up a Debian package repository. It does not describe the format of a Debian repository.

Care has been taken to provide the most accurate information at the time of writing. Please fix any identified mistakes.

APT Archive Types

There are 2 kinds of repositories from user's perspective:

archive style

apt line


secure APT


official archive

"deb http://example.org/debian unstable main"




trivial archive

"deb http://example.org/debian ./"




These archives have different meta-data structure. Both archives can store actual package files. Many older repository HOWTOs (e.g. old "Debian Reference (sarge)" and "APT HOWTO (sarge)") address creation of a "trivial archive" and are problematic since the "trivial archive" lacks support for apt-pinning meta-data used by APT Preferences due to the collision of 2 types of Release files.

For the secure APT compatibility, the modern package archive must be signed by the GPG.


APT Archive Generation Tools

The full package archive similar to the official archive can be created using:

  • dak
  • mini-dak

The Private Package Archive (PPA) can be created on a web server with a shell account using:

  • reprepro
  • mini-dinstall

Both people.debian.org and alioth.debian.org are installed with these packages. The PPA archives created on these hosts should only be used for small low-volume experimental archives only.

Do not run high-volume repositories without consulting the host server's maintainer(s).

dak (Debian Archive Kit)

  • Goals: Hosting the official Debian repositories.
  • Pros:
    • It's the official solution
  • Cons:
    • Depends on python and PostgreSQL
    • Lack of documentation
    • Designed for large repositories.
  • Download: git repository.

  • Distributions: not in Debian
  • Dependencies:
    • python
    • postgresql (optional)
  • Automatic repositories: Yes
  • Incoming mechanism: Yes
  • Pools: Yes
  • GPG signing: Yes
  • Wiki Page: dak


  • Goals: Hosting new Debian architectures (Partial and lightweight reimplementation of dak in shell script and with no database dependencies)
  • Pros:
    • Easy to setup: edit a config file and run a script to generate the whole structure
    • No database (the pool is the database)
    • All .changes files kept for later possible importing into the master repository
    • Supports mail notifications and does extensive logging
    • Auto package obsoleting
    • Repository snapshotting
    • Supports multiple suites from the Distribution field on the .changes file
    • Additionally supports multipool (splitting each arch into its own pool, to ease partial mirroring)
    • Supports upload ACLs based on gpg public keys
    • Mirror push via ssh
  • Cons:
    • Slow on huge repositories (due to not using a real db mainly)
    • Has been written and tested mainly as a slave archive, so might have some hardcoded stuff which should be fixed to make it work as a master server
    • Still has some quirks to be fixed
  • Download: http://www.hadrons.org/~guillem/debian/mini-dak/

  • Distributions: not in Debian
  • Dependencies: ('grep Requires: *' on the source tree)
    • apt-utils
    • procmail
    • gnupg
    • wget
    • ssh (optional)
    • bzip2 (optional)
    • quinn-diff (optional)
  • Automatic repositories: Yes
  • Incoming mechanism: Yes
  • Pools: Yes
  • GPG signing: Yes
  • Sites using it:

reprepro for new packages



  • Goals: Make a simpler version of dak.
  • Pros:
    • Easy to use incoming mechanism - even on remote systems - by using a cron-job
    • Packages can be moved into a distribution by
      1. reading the Distribution value from .changes file or
      2. directly putting the whole package into a distributions-incoming directory.
    • Standard repository (can be pinned)
  • Cons:
    • No Pool-architecture at the moment
    • Some useful checks are missing
    • Cleaning needs to be done manually
  • Package: debarchiver

  • Distributions: oldstable, stable, testing, unstable

  • Dependencies: unstable/devel/debarchiver

    • adduser
    • apt-utils (recommended) | dpkg-dev
    • opalmod (Perl modules)
    • gnupg (optional)
  • Automatic repositories: Yes
  • Incoming mechanism: Yes
  • Pools: No (but suggested somewhere at BTS).

  • GPG signing: Yes (with gnupg, post-Sarge feature).
  • HOWTOs:
  • An example of a repository produced with debarchiver.


  • Goals: Lightweight replacement for dak using a pool layout.
  • Pros:
    • No external dependencies
    • Easy to use incoming mechanism
    • Standard repository (can be pinned)
  • Cons:
    • Not actively maintained since 2008-10-30 (see latest development)

    • no checking of older packages being replaced with new ones
    • no notification of what is going on (no mails when new packages are added)
  • Package: debpool (REMOVED)

  • Distributions: experimental

  • Dependencies:
    • perl
    • gnupg (optional)
  • Automatic repositories: Yes
  • Incoming mechanism: Yes
  • Pools: Yes
  • GPG signing: Yes (with gnupg).
  • Wiki page: debpool


  • Goals: Maintain multiple snapshots from upstream distros, to permit staging.
  • Pros:
    • Fast
    • No database server needed (BerkeleyDB)
  • Cons:
    • Lack of documentation
    • Hasn't been released (No version available, SVN repo has only trunk).
  • Download: http://code.google.com/p/debmarshal/

  • Distributions: not in Debian
  • Automatic repositories: Yes
  • Incoming mechanism: Yes
  • Pools: Yes
  • GPG signing: Yes
  • Wiki page: debmartial

  • Presentation: ODP and PDF files

Built by Google for their use.


  • Goals: Superset of dpkg-scanpackages and dpkg-scansources.
  • Pros:
    • Does not rely on any external programs aside from gzip.
    • Creates Release and Contents files without providing *.changes
  • Cons:
    • Can be slow on large repositories, unless the input file (?FileList) is sorted first (the sort command works).

    • ?
  • Package: apt

  • Distributions: oldstable, stable, testing, unstable, experimental

  • Dependencies: unstable/admin/apt-utils

  • Automatic repositories: No (Yes with dupload)
  • Incoming mechanism: No (Yes with custom move cron script with dupload)
  • Pools: Yes
  • GPG signing: No (Yes with dupload with script)
  • HOWTOs:

dpkg-scanpackages and dpkg-scansources

  • Goals: Generate Packages index files
  • Pros:
    • Use only bare bone tool provided by dpkg
    • Creates Release and Contents files without providing *.changes with additional scripts.
  • Cons:
    • Cannot create Release or Contents files by themselves
  • Package: dpkg

  • Distributions: oldstable, stable, testing, unstable

  • Dependencies: unstable/utils/dpkg-dev

  • Automatic repositories: No
  • Incoming mechanism: No
  • Pools: No
  • GPG signing: No
  • HOWTO: Aaron Isotton how-to

  • mkdebidx is a shell (mksh) script wrapping dpkg-scanpackages, dpkg-scansources, generating Release and Release.gpg files, and producing a nice XHTML/1.1 index (currently only package-centric view, but dist-/suite-centric views planned) of packages in a full, pinnable, repository with multiple dists and suites (only scales up to a hundred or two packages though; with 904 packages in a repository at the employer, 900 of them in one dist+suite, it takes a while to finish but still works). There may be plans to write a FusionForge plugin for repository handling based on this.


  • Goals: manage local repositories, snapshot them and publish
  • Pros:
    • supports multiple versions of package in one repo
    • has supported for mirroring in the same tool
  • Download & Documentation: http://www.aptly.info/

  • Distributions: testing, unstable

  • Source: GitHub

APT Archive Mirroring Tools


reprepro for partial mirroring


  • Description: Debian partial mirror script, with ftp and package pool support
  • Package: debmirror


  • Description: APT sources mirroring tool
  • Package: apt-mirror



  • Description: Maintain Debian packages in a package pool
  • Package: apt-move


  • Description: Mirror remote repositories and manage local repositories, take snapshots, merge them, pull packages from one snapshot to another, publish snapshots as repositories
  • Download & Documentation: http://www.aptly.info/

  • Distributions: testing, unstable

  • Source: GitHub

  • Presentation: PDF

anonftpsync (deprecated)

  • Description: The previous official mirroring tool
  • Pros:
    • Ease of use and few dependencies,
    • Bash script
  • Cons:
    • Lacks flexibility
    • Does not implement latest (2012 A.D.) mirror features (deprecated)
  • Download: anonftpsync

  • Package: not in Debian
  • Dependencies: bash, rsync

See also