Reprepro
(→HOWTO) |
|||
| (17 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | '''Reprepro''' is a tool for managing APT repositories. It's definitely much more versatile than the simple script ''update-repository'' that we have been using before. | + | '''Reprepro''' is a tool for managing [[APT repository|APT repositories]]. It's definitely much more versatile than the simple script ''update-repository'' that we have been using before. |
Reprepro is able to manage multiple repositories for multiple distribution versions and one package pool. It can process updates from an <tt>incoming</tt> directory, copy package (references) between distribution versions, list all packages and/or package versions available in the repository, etc. | Reprepro is able to manage multiple repositories for multiple distribution versions and one package pool. It can process updates from an <tt>incoming</tt> directory, copy package (references) between distribution versions, list all packages and/or package versions available in the repository, etc. | ||
| Line 26: | Line 26: | ||
To see all packages in a given distribution, use | To see all packages in a given distribution, use | ||
| − | + | reprepro list ''distribution-name'' | |
To find all packages in all repositories, use | To find all packages in all repositories, use | ||
| Line 33: | Line 33: | ||
=== Automatically import files from an <tt>incoming/</tt> directory === | === Automatically import files from an <tt>incoming/</tt> directory === | ||
| − | Reprepro can automatically import packages from an upload directory, as long as all the package fields are setup correctly with the right distribution and component names. It's also vital that the <tt>.changes</tt> files are present. When all these conditions are met, you can use: | + | Reprepro can automatically import packages from an upload directory, as long as all the package fields are setup correctly with the right distribution and component names. It's also vital that the <tt>.changes</tt> files are present. When all these conditions are met, and all these files have been uploaded to <tt>/srv/wikimedia/incoming</tt> (e.g. using <tt>dupload</tt>), you can use: |
| + | # reprepro processincoming default | ||
| − | == | + | It uses the rules defined in the file <tt>/srv/wikimedia/conf/incoming</tt> |
| − | + | ||
| − | + | If the package is rejected by reprepro because one of the package control fields are wrong, or you want to override them for some other reason, use an ''override'' file (see below). | |
| − | + | ||
| − | + | It's best to check whether the <tt>/srv/wikimedia/incoming/</tt> directory is empty after using <tt>procesincoming</tt>, because reprepro should have moved/deleted all imported files. Any remaining files have not been processed. | |
| − | + | ||
| − | + | === Importing packages === | |
| − | + | It's always best to have reprepro fully manage all package aspects using the <tt>.changes</tt> that was created during the build of the package (e.g. using [[Pbuilder]]). When the <tt>.changes</tt> file is present along with all files list therein, reprepro can handle it all with the <tt>reprepro include</tt> command: | |
| + | # reprepro -C component-name include wikimedia-distribution-name path-to-.changes-file | ||
| + | |||
| + | For example: | ||
| + | |||
| + | # reprepro -C main include hardy-wikimedia php5-apc_3.1.3p1-1wm1_amd64.changes | ||
| + | |||
| + | For ''component'', use the following as a guide: | ||
| + | |||
| + | ; main : for Wikimedia native packages, as well as Debian/Ubuntu packages that have had ''source-modifications'' | ||
| + | ; universe : for existing Debian/Ubuntu packages that just have been recompiled/''backported'' for the given distribution. | ||
| + | |||
| + | For ''distribution'', use the distribution that the package has been compiled ''for'', and ''under''. Usually, any given compiled package should be for ''one'' distribution only, e.g. ''hardy-wikimedia'' '''OR''' ''lucid-wikimedia''. This should match the field in the package's Changelog. Only in special circumstances a given package can be used under multiple distribution versions, .e.g. if the package contains only scripts (no binaries). '''Only do this if you've tested it and are sure this is working'''. In this case, include the package in the ''oldest'' distribution version, and then copy the package references using <tt>reprepro copy</tt> (see below). | ||
| + | |||
| + | When no <tt>.changes</tt> file is available, for example because you didn't build the package yourself, you can use <tt>reprepro includedsc</tt> and <tt>includedeb</tt>: | ||
| + | # reprepro -C universe includedsc lucid-wikimedia varnish_2.1.2-1.dsc | ||
| + | # reprepro -C universe includedeb lucid-wikimedia varnish_2.1.2-1_amd64.deb | ||
| + | # reprepro -C universe includedeb lucid-wikimedia libvarnish1_2.1.2-1_amd64.deb | ||
| + | # reprepro -C universe includedeb lucid-wikimedia libvarnish-dev_2.1.2-1_amd64.deb | ||
| + | |||
| + | Be aware that reprepro will remove older versions of packages without asking. They are no longer available in the pool (<tt>/srv/wikimedia/pool</tt>) either. However, <tt>/srv/wikimedia/</tt> is backed up using Amanda on [[tridge]], and many packages should be available in subversion as well. | ||
| + | |||
| + | === Removing packages === | ||
| + | A given package can be removed from a distribution using | ||
| + | # reprepro remove ''distribution-name'' ''package-name'' | ||
| + | For example: | ||
| + | # reprepro remove hardy-wikimedia facter | ||
| + | |||
| + | === Using the ''override'' file === | ||
| + | When we are building our own packages, we should make sure that all control fields (such as the distribution name, component, priority etc.) are set correctly. Please rebuild your package if not. | ||
| + | |||
| + | However, occasionally it is necessary to override fields on a previously built package, which we don't want to modify the source of and/or rebuild. Ubuntu often does the same, and just retrieves packages from Debian Unstable and overrides a few fields using an ''override'' file. | ||
| + | |||
| + | We have an ''override'' file as well, in <tt>/srv/wikimedia/conf/deb-override</tt>. It's format is: | ||
| + | # packagename fieldname newvalue | ||
| + | |||
| + | As an example, our Varnish packages are coming straight from Debian Unstable (like in Ubuntu), and can be imported fine into Lucid as long as we override some package fields: | ||
| + | <pre> | ||
| + | varnish Distribution lucid | ||
| + | libvarnish1 Distribution lucid | ||
| + | libvarnish-dev Distribution lucid | ||
| + | </pre> | ||
| + | |||
| + | === Copying between distributions === | ||
| + | In some cases, notably when no compiled binaries are involved, a given package build can be used for multiple distribution versions. This is for example the case with most native Wikimedia packages, which just contain (shell) scripts and can easily support multiple distribution versions (e.g. Hardy to Lucid). It would be a waste of time and work to make separate builds for these packages, so we include only one copy of these packages into multiple distributions. | ||
| + | |||
| + | To do this, build the package for the ''oldest'' distribution that is supported, e.g. <tt>hardy-wikimedia</tt>. Then, import it into this distribution: | ||
| + | # reprepro -C main include hardy-wikimedia wikimedia-base wikimedia-base_0.26_amd64.changes | ||
| + | # reprepro ls wikimedia-base | ||
| + | wikimedia-base | 0.26 | hardy-wikimedia | amd64, source | ||
| + | |||
| + | Then, copy it to the other supported distributions, e.g. ''karmic-wikimedia'' and ''lucid-wikimedia'': | ||
| + | # reprepro copy karmic-wikimedia hardy-wikimedia wikimedia-base | ||
| + | # reprepro copy lucid-wikimedia hardy-wikimedia wikimedia-base | ||
| + | # reprepro ls wikimedia-base | ||
| + | wikimedia-base | 0.26 | hardy-wikimedia | amd64, source | ||
| + | wikimedia-base | 0.26 | karmic-wikimedia | amd64, source | ||
| + | wikimedia-base | 0.26 | lucid-wikimedia | amd64, source | ||
| + | |||
| + | === Adding i386 === | ||
| + | |||
| + | UEC images will try to pull i386 things via apt-get update, so we need to support i386 in our apt configuration. In /srv/wikimedia/conf/distributions, add i386 to the Architectures line for the version you need, and run: reprepro flood <version>-wikimedia | ||
[[Category:Ubuntu]] [[Category:Package management]] | [[Category:Ubuntu]] [[Category:Package management]] | ||
Latest revision as of 19:09, 30 April 2012
Reprepro is a tool for managing APT repositories. It's definitely much more versatile than the simple script update-repository that we have been using before.
Reprepro is able to manage multiple repositories for multiple distribution versions and one package pool. It can process updates from an incoming directory, copy package (references) between distribution versions, list all packages and/or package versions available in the repository, etc.
Reprepro maintains an internal database (a .DBM file) of the contents of the repository, which makes it quite fast and efficient.
It's installed from the Debian package reprepro, and is configured using the files in /srv/wikimedia/conf/. I added an environment variable to /etc/environment for convenience:
REPREPRO_BASE_DIR=/srv/wikimedia
Contents |
[edit] HOWTO
This section explains the most commonly needed actions/tasks involving reprepro.
[edit] List all package versions in the repositories
For a given package name, use
reprepro ls packagename
For example:
# reprepro ls puppet puppet | 2.6.1-0ubuntu1~ppa1~hardy3 | hardy-wikimedia | amd64, source puppet | 2.6.1-0ubuntu1~ppa1~lucid1 | lucid-wikimedia | amd64, source
This shows that there are two different builds of the same package version in the repositories hardy-wikimedia and lucid-wikimedia. There is clearly no puppet package in the karmic-wikimedia repository.
To see all packages in a given distribution, use
reprepro list distribution-name
To find all packages in all repositories, use
reprepro dumpreferences
or a variant thereof (see reprepro help or man reprepro).
[edit] Automatically import files from an incoming/ directory
Reprepro can automatically import packages from an upload directory, as long as all the package fields are setup correctly with the right distribution and component names. It's also vital that the .changes files are present. When all these conditions are met, and all these files have been uploaded to /srv/wikimedia/incoming (e.g. using dupload), you can use:
# reprepro processincoming default
It uses the rules defined in the file /srv/wikimedia/conf/incoming
If the package is rejected by reprepro because one of the package control fields are wrong, or you want to override them for some other reason, use an override file (see below).
It's best to check whether the /srv/wikimedia/incoming/ directory is empty after using procesincoming, because reprepro should have moved/deleted all imported files. Any remaining files have not been processed.
[edit] Importing packages
It's always best to have reprepro fully manage all package aspects using the .changes that was created during the build of the package (e.g. using Pbuilder). When the .changes file is present along with all files list therein, reprepro can handle it all with the reprepro include command:
# reprepro -C component-name include wikimedia-distribution-name path-to-.changes-file
For example:
# reprepro -C main include hardy-wikimedia php5-apc_3.1.3p1-1wm1_amd64.changes
For component, use the following as a guide:
- main
- for Wikimedia native packages, as well as Debian/Ubuntu packages that have had source-modifications
- universe
- for existing Debian/Ubuntu packages that just have been recompiled/backported for the given distribution.
For distribution, use the distribution that the package has been compiled for, and under. Usually, any given compiled package should be for one distribution only, e.g. hardy-wikimedia OR lucid-wikimedia. This should match the field in the package's Changelog. Only in special circumstances a given package can be used under multiple distribution versions, .e.g. if the package contains only scripts (no binaries). Only do this if you've tested it and are sure this is working. In this case, include the package in the oldest distribution version, and then copy the package references using reprepro copy (see below).
When no .changes file is available, for example because you didn't build the package yourself, you can use reprepro includedsc and includedeb:
# reprepro -C universe includedsc lucid-wikimedia varnish_2.1.2-1.dsc # reprepro -C universe includedeb lucid-wikimedia varnish_2.1.2-1_amd64.deb # reprepro -C universe includedeb lucid-wikimedia libvarnish1_2.1.2-1_amd64.deb # reprepro -C universe includedeb lucid-wikimedia libvarnish-dev_2.1.2-1_amd64.deb
Be aware that reprepro will remove older versions of packages without asking. They are no longer available in the pool (/srv/wikimedia/pool) either. However, /srv/wikimedia/ is backed up using Amanda on tridge, and many packages should be available in subversion as well.
[edit] Removing packages
A given package can be removed from a distribution using
# reprepro remove distribution-name package-name
For example:
# reprepro remove hardy-wikimedia facter
[edit] Using the override file
When we are building our own packages, we should make sure that all control fields (such as the distribution name, component, priority etc.) are set correctly. Please rebuild your package if not.
However, occasionally it is necessary to override fields on a previously built package, which we don't want to modify the source of and/or rebuild. Ubuntu often does the same, and just retrieves packages from Debian Unstable and overrides a few fields using an override file.
We have an override file as well, in /srv/wikimedia/conf/deb-override. It's format is:
# packagename fieldname newvalue
As an example, our Varnish packages are coming straight from Debian Unstable (like in Ubuntu), and can be imported fine into Lucid as long as we override some package fields:
varnish Distribution lucid libvarnish1 Distribution lucid libvarnish-dev Distribution lucid
[edit] Copying between distributions
In some cases, notably when no compiled binaries are involved, a given package build can be used for multiple distribution versions. This is for example the case with most native Wikimedia packages, which just contain (shell) scripts and can easily support multiple distribution versions (e.g. Hardy to Lucid). It would be a waste of time and work to make separate builds for these packages, so we include only one copy of these packages into multiple distributions.
To do this, build the package for the oldest distribution that is supported, e.g. hardy-wikimedia. Then, import it into this distribution:
# reprepro -C main include hardy-wikimedia wikimedia-base wikimedia-base_0.26_amd64.changes # reprepro ls wikimedia-base wikimedia-base | 0.26 | hardy-wikimedia | amd64, source
Then, copy it to the other supported distributions, e.g. karmic-wikimedia and lucid-wikimedia:
# reprepro copy karmic-wikimedia hardy-wikimedia wikimedia-base # reprepro copy lucid-wikimedia hardy-wikimedia wikimedia-base # reprepro ls wikimedia-base wikimedia-base | 0.26 | hardy-wikimedia | amd64, source wikimedia-base | 0.26 | karmic-wikimedia | amd64, source wikimedia-base | 0.26 | lucid-wikimedia | amd64, source
[edit] Adding i386
UEC images will try to pull i386 things via apt-get update, so we need to support i386 in our apt configuration. In /srv/wikimedia/conf/distributions, add i386 to the Architectures line for the version you need, and run: reprepro flood <version>-wikimedia