Differences between revisions 84 and 85
Revision 84 as of 2014-03-13 09:48:23
Size: 16304
Editor: ?AndreySmirnov
Comment:
Revision 85 as of 2014-05-14 09:56:58
Size: 16301
Comment: mini-dinstall depends on python
Deletions are marked like this. Additions are marked like this.
Line 132: Line 132:
  * python2.3   * python

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

apt-pinning

secure APT

status

official archive

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

Yes

Yes

preferred

trivial archive

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

No

Yes

deprecated

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.

References:

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

mini-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

mini-dinstall

debarchiver

  • 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.

debpool

  • 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

DebMarshal

  • 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.

apt-ftparchive

  • 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.

aptly

  • 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: not in Debian
  • Source: GitHub

APT Archive Mirroring Tools

ftpsync

reprepro for partial mirroring

debmirror

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

apt-mirror

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

debpartial-mirror

apt-move

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

aptly

  • 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: not in Debian
  • 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


CategoryPackageManagement