REPREPRO(1)

๐Ÿ’– REPREPRO(1) ๐Ÿ’–

Okay bestie, this is reprepro โ€” the manual page for the tool that produces, manages and syncs a local repository of Debian packages. Itโ€™s giving repository main character energy, and weโ€™re gonna get through it together. ๐Ÿ‘‘

๐ŸŒธ NAME ๐ŸŒธ

reprepro โ€” produce, manage and sync a local repository of Debian packages.

โœจ SYNOPSIS โœจ

reprepro --help

reprepro [ options ] command [ per-command-arguments ]

๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

Okay so reprepro is a tool to manage a repository of Debian packages (.deb, .udeb, .dsc, ...). It stores files either being injected manually or downloaded from some other repository (partially) mirrored into a pool/ hierarchy. Managed packages and checksums of files are stored in a Berkeley DB database file, so no database server is needed. Checking signatures of mirrored repositories and creating signatures of the generated Package indices is supported.

Former working title of this program was mirrorer. Lore unlocked, I guess. ๐Ÿ’…

๐Ÿ‘‘ GLOBAL OPTIONS ๐Ÿ‘‘

Options can be specified before the command. Each affects a different subset of commands and is ignored by other commands. So yes, some of these are lowkey picky about which command they hang out with โ€” thatโ€™s just the vibe. ๐Ÿซถ

  • -h, --help โ€” Displays a short list of options and commands with description.
  • -v, -V, --verbose โ€” Be more verbose. Can be applied multiple times. One uppercase -V counts as five lowercase -v. Highkey a volume knob for your terminal. ๐Ÿ”Š
  • -s, --silent โ€” Be less verbose. Can be applied multiple times. One -v and one -s cancel each other out.
  • -f, --force โ€” This option is ignored, as it no longer exists. Not me looking for a button thatโ€™s literally gone. ๐Ÿ’€
  • -b, --basedir basedir โ€” Sets the base-dir all other default directories are relative to. If none is supplied and the REPREPRO_BASE_DIR environment variable is not set either, the current directory will be used.
  • --outdir outdir โ€” Sets the base-dir of the repository to manage, i.e. where the pool/ subdirectory resides. And in which the dists/ directory is placed by default. If this starts with +b/, it is relative to basedir.

The default for this is basedir.

  • --confdir confdir โ€” Sets the directory where the configuration is searched in. If this starts with +b/, it is relative to basedir. If none is given, +b/conf (i.e. basedir/conf) will be used.
  • --distdir distdir โ€” Sets the directory to generate index files relatively to. (i.e. things like Packages.gz, Sources.gz and Release.gpg.) If this starts with +b/, it is relative to basedir, if starting with +o/ relative to outdir. If none is given, +o/dists (i.e. outdir/dists) is used.
Note: apt has dists hard-coded in it, so this is mostly only useful for testing or when your webserver pretends another directory structure than your physical layout.
Warning: Beware when changing this forth and back between two values not ending in the same directory. Reprepro only looks if files it wants are there. If nothing of the content changed and there is a file it will not touch it, assuming it is the one it wrote last time, assuming any different --distdir ended in the same directory. So either clean a directory before setting --distdir to it or do an export with the new one first to have a consistent state.
  • --logdir logdir โ€” The directory where files generated by the Log: directive are stored if they have no absolute path. If this starts with +b/, it is relative to basedir, if starting with +o/ relative to outdir, with +c/ relative to confdir. If none is given, +b/logs (i.e. basedir/logs) is used.
  • --dbdir dbdir โ€” Sets the directory where reprepro keeps its databases. If this starts with +b/, it is relative to basedir, if starting with +o/ relative to outdir, with +c/ relative to confdir. If none is given, +b/db (i.e. basedir/db) is used.
Note: This is permanent data, no cache. One has almost to regenerate the whole repository when this is lost.
  • --listdir listdir โ€” Sets the directory where it downloads indices to when importing from other repositories. This is temporary data and can be safely deleted when not in an update run. If this starts with +b/, it is relative to basedir, if starting with +o/ relative to outdir, with +c/ relative to confdir. If none is given, +b/lists (i.e. basedir/lists) is used.
  • --morguedir morguedir โ€” Files deleted from the pool are stored into morguedir. If this starts with +b/, it is relative to basedir, if starting with +o/ relative to outdir, with +c/ relative to confdir. If none is given, deleted files are just deleted.
  • --methoddir methoddir โ€” Look in methoddir instead of /usr/lib/apt/methods for methods to call when importing from other repositories.
  • -C, --component components โ€” Limit the specified command to this components only. This will force added packages to this components, limit removing packages from this components, only list packages in this components, and/or otherwise only look at packages in this components, depending on the command in question. Multiple components are specified by separating them with |, as in -C 'main|contrib'.
  • -A, --architecture architectures โ€” Limit the specified command to this architectures only. (i.e. only list such packages, only remove packages from the specified architectures, or otherwise only look at/act on this architectures depending on the specific command.) Multiple architectures are specified by separating them with |, as in -A 'sparc|i386'. Note that architecture all packages can be included to each architecture but are then handled separately. Thus by using -A in a specific way one can have different versions of an architecture all package in different architectures of the same distribution.
  • -T, --type dsc|deb|udeb โ€” Limit the specified command to this packagetypes only. (i.e. only list such packages, only remove such packages, only include such packages, ...)
  • -S, --section section โ€” Overrides the section of inclusions. (Also override possible override files.)
  • -P, --priority priority โ€” Overrides the priority of inclusions. (Also override possible override files.)
  • --export=(silent-never|never|changed|lookedat|force) โ€” This option specify whether and how the high level actions (e.g. install, update, pull, delete) should export the index files of the distributions they work with.
  • --export=lookedat โ€” In this mode every distribution the action handled will be exported, unless there was an error possibly corrupting it. Note that only missing files and files whose intended content changed between before and after the action will be written. To get a guaranteed current export, use the export action. For backwards compatibility, lookedat is also available under the old name normal. The name normal is deprecated and will be removed in future versions.
  • --export=changed โ€” In this mode every distribution actually changed will be exported, unless there was an error possibly corrupting it. (i.e. if nothing changed, not even missing files will be created.) Note that only missing files and files whose intended content changed between before and after the action will be written. To get a guaranteed current export, use the export action.
  • --export=force โ€” Always export all distributions looked at, even if there was some error possibly bringing it into a inconsistent state.
  • --export=never โ€” No index files are exported. You will have to call export later. Note that you most likely additionally need the --keepunreferencedfiles option, if you do not want some of the files pointed to by the untouched index files to vanish.
  • --export=silent-never โ€” Like never, but suppress most output about that.
  • --ignore=what โ€” Ignore errors of type what. See the section ERROR IGNORING for possible values.
  • --nolistsdownload โ€” When running update, checkupdate or predelete do not download any Release or index files. This is hardly useful except when you just run one of those command for the same distributions. And even then reprepro is usually good in not downloading except Release and Release.gpg files again.
  • --nothingiserror โ€” If nothing was done, return with exitcode 1 instead of the usual 0. Note that "nothing was done" means the primary purpose of the action in question. Auxiliary actions (opening and closing the database, exporting missing files with --export=lookedat, ...) usually do not count. Also note that this is not very well tested. If you find an action that claims to have done something in some cases where you think it should not, please let me know.
  • --keeptemporaries โ€” Do not delete temporary .new files when exporting a distribution fails. (reprepro first create .new files in the dists directory and only if everything is generated, all files are put into their final place at once. If this option is not specified and something fails, all are deleted to keep dists clean).
  • --keepunreferencedfiles โ€” Do not delete files that are no longer used because the package they are from is deleted/replaced with a newer version from the last distribution it was in.
  • --keepunusednewfiles โ€” The include, includedsc, includedeb and processincoming by default delete any file they added to the pool that is not marked used at the end of the operation. While this keeps the pool clean and allows changing before trying to add again, this needs copying and checksum calculation every time one tries to add a file.
  • --keepdirectories โ€” Do not try to rmdir parent directories after files or directories have been removed from them. (Do this if your directories have special permissions you want keep, do not want to be pestered with warnings about errors to remove them, or have a buggy rmdir call deleting non-empty directories.)
  • --ask-passphrase โ€” Ask for passphrases when signing things and one is needed. This is a quick and dirty and unsafe implementation using the obsolete getpass(3) function with the description gpgme is supplying. So the prompt will look quite funny and support for passphrases with more than 8 characters depend on your libc. Use of this option is not recommended. Use gpg-agent with pinentry instead.

...and yeah, real talk about --ask-passphrase: with current versions of gnupg you need to set pinentry-mode loopback in your .gnupg/gpg.conf file to use it. Without that option, gnupg uses the much safer and recommended pinentry instead. ๐Ÿ’… Like, gnupg is being the responsible friend here, ok?

  • --noskipold โ€” when updating, don't skip targets where no new index files and no files marked as already processed are available. If you changed a script to preprocess downloaded index files, or changed a Listfilter, you most likely want to call reprepro with --noskipold. so basically: you touched the recipe, now re-run the whole thing bestie.
  • --waitforlock count โ€” if there's a lockfile saying another reprepro instance is currently using the database, retry count times after waiting for 10 seconds each time. Default is 0, which means error out instantly. ๐Ÿ˜ค no patience, no waiting, just vibes and an error.
  • --spacecheck full|none โ€” default is full: in the update commands, check for every to-be-downloaded file which filesystem it's on and how much space is left. To disable this behaviour, use none.
  • --dbsafetymargin bytes-count โ€” if checking for free space, reserve bytes-count bytes on the filesystem containing the db/ directory. Default is 104857600 (i.e. 100MB), which is quite large. But as there's no way to know in advance how large the databases will grow and libdb is extremely touchy in that regard, lower only when you know what you do. ๐Ÿ’€ lower only when you know what you do โ€” she means it.
  • --safetymargin bytes-count โ€” if checking for free space, reserve bytes-count bytes on filesystems not containing the db/ directory. Default is 1048576 (i.e. 1MB).
  • --noguessgpgtty โ€” don't set the environment variable GPG_TTY, even when it's not set, stdin is a terminal and /proc/self/fd/0 is a readable symbolic link. โœจ
  • --gnupghome โ€” set the GNUPGHOME environment variable to the given directory as argument to this option. And your gpg will most likely use the content of this variable instead of "~/.gnupg". Take a look at gpg(1) to be sure. This option in the command line is usually not very useful, as it's possible to set the environment variable directly. Its main reason for existence is that it can be used in conf/options. ๐Ÿงš it's giving "I exist for the config file girlies".
  • --list-max count โ€” limits the output of list, listmatched and listfilter to the first count results. Default is 0, which means unlimited.
  • --list-skip count โ€” omits the first count results from the output of list, listmatched and listfilter.
  • --list-format format โ€” set the output format of the list, listmatched and listfilter commands. The format is similar to dpkg-query's --showformat: fields are specified as ${fieldname} or ${fieldname;length}. Zero length or no length means unlimited. Positive numbers mean fill with spaces right, negative fill with spaces left.

\n, \r, \t, \0 are new-line, carriage-return, tabulator and zero-byte. Backslash (\) can be used to escape every non-letter-or-digit. ๐ŸŽ€

The special field names $identifier, $architecture, $component, $type, $codename denote where the package was found.

The special field names $source and $sourceversion denote the source and source version a package belongs to. (i.e. ${$source} will either be the same as ${source} (without a possible version in parentheses at the end) or the same as ${package}.)

The special field names $basename, $filekey and $fullfilename denote the first package file part of this entry (i.e. usually the .deb, .udeb or .dsc file) as basename, as filekey (filename relative to the outdir) and the full filename with outdir prepended (i.e. as relative or absolute as your outdir (or basedir if you did not set outdir) is).

When --list-format is not given or NONE, then the default is equivalent to ${$identifier} ${package} ${version}\n.

no cap, this part is a whole warning section: escaping digits or letters not in the above list, using dollars not escaped outside specified constructs, or any field names not listed as special and not consisting entirely out of letters, digits and minus signs have undefined behaviour and might change meaning without any further notice. ๐Ÿ™ˆ undefined behaviour, bestie โ€” do not test her.

If you give this option on the command line, don't forget that $ is also interpreted by your shell. So you have to properly escape it. For example by putting the whole argument to --list-format in single quotes. ๐Ÿ’… the shell is NOT your friend here.

  • --show-percent โ€” when downloading packages, show each completed percent of completed package downloads together with the size of completely downloaded packages. (Repeating this option increases the frequency of this output.) ๐Ÿ”ฅ
  • --onlysmalldeletes โ€” the pull and update commands will skip every distribution in which one target loses more than 20% of its packages (and at least 10). Using this option (or putting it in the options config file) can avoid removing large quantities of data, but means you might often give --noonlysmalldeletes to override it. safety rails on, queen.
  • --restrict src[=version|:type] โ€” restrict a pull or update to only act on packages belonging to source-package src. Any other package will not be updated (unless it matches a --restrict-bin). Only packages that would otherwise be updated or are at least marked with hold in a FilterList or FilterSrcList will be updated.

The action can be restricted to a source version using an equal sign, or changed to another type (see FilterList) using a colon.

This option can be given multiple times to list multiple packages, but each package may only be named once (even when there are different versions or types). โญ

  • --restrict-binary name[=version|:type] โ€” like --restrict but restrict to binary packages (.deb and .udeb). Source packages are not upgraded unless they appear in a --restrict.
  • --restrict-file filename โ€” like --restrict but read a whole file in the FilterSrcList format. ๐Ÿ“„
  • --restrict-file-bin filename โ€” like --restrict-bin but read a whole file in the FilterList format.
  • --endhook hookscript โ€” run the specified hookscript once reprepro exits. It will get the usual REPREPRO_* environment variables set (or unset) and additionally a variable REPREPRO_EXIT_CODE that is the exit code with which reprepro would have exited (the hook is always called once the initial parsing of global options and the command name is done, no matter if reprepro did anything or not). Reprepro will return to the calling process with the exit code of this script. Reprepro has closed all its databases and removed all its locks, so you can run reprepro again in this script (unless someone else did so in the same repository before, of course). ๐Ÿฆ‹

The only advantage over running that command always directly after reprepro is that you can have some environment variables set and cannot so easily forget it if this option is in conf/options.

The script is supposed to be located relative to confdir, unless its name starts with /, ./, +b/, +o/, or +c/ and the name may not start (except in the cases given before) with a +.

An example script looks like:

#!/bin/sh

if [ "$REPREPRO_EXIT_CODE" -ne 0 ] ; then
     exit "$REPREPRO_EXIT_CODE"
fi

echo "congratulations, reprepro with arguments: $*"
echo "seems to have run successfully. REPREPRO_ part of the environment is:"
set | grep ^REPREPRO_

exit 0
  • --outhook hookscript โ€” hookscript is called with a .outlog file as argument (located in logdir) containing a description of all changes made to outdir. ๐Ÿซถ

The script is supposed to be located relative to confdir, unless its name starts with /, ./, +b/, +o/, or +c/ and the name may not start (except in the cases given before) with a +.

For a format of the .outlog files generated for this script, see the manual.html shipped with reprepro.


๐Ÿ‘‘ COMMANDS ๐Ÿ‘‘

finally, the actual verbs. the things she can DO.

  • ### ๐Ÿ“ฆ export [ codenames ]

Generate all index files for the specified distributions.

This regenerates all files unconditionally. It is only useful if you want to be sure dists is up to date, you called some other actions with --export=never before, or you want to create an initial empty but fully equipped dists/codename directory. โœจ

  • ### ๐Ÿ”— [ --delete ] createsymlinks [ codenames ]

Creates suite symbolic links in the dists/-directory pointing to the corresponding codename.

It will not create links when multiple of the given codenames would be linked from the same suite name, or if the link already exists (though when --delete is given it will delete already existing symlinks). ๐ŸŽ€

  • ### ๐Ÿ“‹ list codename [ packagename ]

List all packages (source and binary, except when -T or -A is given) with the given name in all components (except when -C is given) and architectures (except when -A is given) of the specified distribution. If no package name is given, list everything. The format of the output can be changed with --list-format. To only get parts of the result, use --list-max and --list-skip. ๐Ÿ’–

  • ### ๐ŸŒธ listmatched codename glob

As list, but does not list a single package, but all packages matching the given shell-like glob. (i.e. *, ? and [chars] are allowed.)

Examples:

reprepro -b . listmatched test2 'linux-*'

...lists all packages starting with linux-. globbing is so iconic of her tbh.

  • ### ๐Ÿงš listfilter codename condition

As list, but does not list a single package, but all packages matching the given condition.

The format of the formulas is those of the dependency lines in Debian packages' control files with some extras. That means a formula consists of names of fields with a possible condition for its content in parentheses. These atoms can be combined with an exclamation mark '!' (meaning not), a pipe symbol '|' (meaning or) and a comma ',' (meaning and). Additionally parentheses can be used to change binding (otherwise '!' binds more than '|' than ','). ๐Ÿ’…๐Ÿ”ฅ

and that's the commands so far โ€” keep reading, there's more coming, don't you DARE close the tab ๐Ÿซถ

Okay so real talk about how the comparing actually works: the values you put in your search expression get compared alphabetically to the headers in the respective index file. Translation? Each little Fieldname (cmp value) chunk of your formula is true for exactly those packages that have, in the Package or Sources file, a line starting with fieldname and a value that is alphabetically cmp to value. Simple as that ๐Ÿ’…

And since reprepro 3.11.0, plot twist: you can use % as your comparison operator, and it means "match this name with shell-style wildcards" (so *, ? and [..] all work). Iconic.

Now, the special field names that start with $? They mean special things (available since 3.11.1, bestie, don't @ me if you're on something ancient):

  • $Version โ€” the version of the package, and heads up: the comparison here is not alphabetical, it's as Debian version strings ๐ŸŽ€
  • $Source โ€” the source name of the package
  • $SourceVersion โ€” the source version of the package
  • $Architecture โ€” the architecture the package is in (listfilter) or is to be put into
  • $Component โ€” the component the package is in (listfilter) or is to be put into
  • $Packagetype โ€” the packagetype of the package

๐ŸŒธ Examples ๐ŸŒธ

reprepro -b . listfilter test2 'Section (== admin)' โ€” this will list all packages in distribution test2 with a Section field, where the value of that field is admin. Slay.

reprepro -b . -T deb listfilter test2 'Source (== blub) | ( !Source , Package (== blub) )' โ€” this finds all .deb Packages with either a Source field of blub, or no Source field and a Package field of blub. (So like, all packages generated by a source package blub, except those that also specify a version number with their Source.) Lowkey a mouthful.

reprepro -b . -T deb listfilter test2 '$Source (==blub)' โ€” this is the better way to do the above (but only available since 3.11.1, so mind the version ๐Ÿ‘€).

reprepro -b . listfilter test2 '$PackageType (==deb), $Source (==blub)' โ€” another way to do it, though it's the less efficient one. Still valid though ๐Ÿซถ

reprepro -b . listfilter test2 'Package (% linux-*-2.6*)' โ€” lists all packages with names starting with linux- and later on having an -2.6 in there. Wildcards doing the absolute most, we love to see it โœจ


๐Ÿ’– COMMANDS (continued) ๐Ÿ’–

  • ls package-name โ€” lists the versions of the specified package across all distributions.
  • lsbycomponent package-name โ€” like ls, but grouped by component (and yes, it prints the component names too).
  • remove codename package-names[=version] ... โ€” deletes packages in the specified distribution that have a package name listed as an argument. You must specify package versions by appending = and the version to the name (no spaces, bestie, none). If you don't give a version, the latest package version gets removed.
โš ๏ธ Heads up: like literally any other operation that removes or replaces a package, the old package's files get unreferenced and may therefore be automatically deleted if that was their last reference and you didn't specify --keepunreferencedfiles. So likeโ€ฆ be aware ๐Ÿ˜ญ
  • removematched codename glob โ€” deletes all packages that listmatched with the same arguments would list. Matchy matchy, deletie deletie.
  • removefilter codename condition โ€” deletes all packages that listfilter with the same arguments would list.
  • removesrc codename source-name [version] โ€” removes all packages in distribution codename belonging to source package source-name. (Limited to those with source version version if you specify it.) If package tracking is activated, it'll use that info to find the packages; otherwise it just traverses all package indices for the distribution. No shortcuts, just vibes ๐Ÿงš
  • removesrcs codename source-name[=version] ... โ€” like removesrc, but you can hand it multiple source names, and source versions must be specified by appending = and the version to the name (again: without spaces).
  • update [ codenames ] โ€” syncs the specified distributions (all of them if none given) as specified in the config with their upstreams. See the description of conf/updates below. This is the main character of the whole sync operation ๐Ÿ”ฅ
  • checkupdate [ codenames ] โ€” same as update, but shows you what it would change instead of actually changing it. A vibe check, basically.
  • dumpupdate [ codenames ] โ€” same as checkupdate, but less suitable for humans and more suitable for computers. Robot mode ๐Ÿค–
  • predelete [ codenames ] โ€” this figures out which packages an update would delete or replace, and removes those packages. Useful for reducing the space needed while upgrading, but there'll be some time where packages are vanished from the lists, so clients will mark them as obsolete. Plus, if you can't download an updated package in the (hopefully) following update run, you'll end up with no package at all instead of an old one. It will also blow up .diff files if you're using the pdiff example or something similar.
๐Ÿ’€ So be careful with this one, or better yet โ€” just get some more space so that update works properly. No cap.
  • cleanlists โ€” deletes all files in listdir (default basedir/lists) that don't belong to any update rule for any distribution. I.e. all files in that directory that no update command in the current configuration can use get deleted. (The files are usually left there, so if they're needed again they don't need to be downloaded again. Though in many easy cases, not even those files will be needed.)
  • pull [ codenames ] โ€” pulls in newer packages into the specified distributions (all if none given) from other distributions in the same repository. See the description of conf/pulls below.
  • checkpull [ codenames ] โ€” same as pull, but shows you what it'd change instead of actually changing it.
  • dumppull [ codenames ] โ€” same as checkpull, but less suitable for humans and more suitable for computers.
  • includedeb codename .deb-filename โ€” includes the given binary Debian package (.deb) in the specified distribution, applying override information and guessing all values that aren't given and are guessable. The โœจ include โœจ of the binary world.
  • includeudeb codename .udeb-filename โ€” same as includedeb, but for .udeb files.
  • includedsc codename .dsc-filename โ€” includes the given Debian source package (.dsc, including other files like .orig.tar.gz, .tar.gz and/or .diff.gz) in the specified distribution, applying override information and guessing all values that aren't given and guessable.
๐ŸŒธ Note that .dsc files do not contain section or priority, but the Sources.gz file needs them. reprepro tries to parse .diff and .tar files for it, but is only able to resolve easy cases. If reprepro fails to extract those automatically, you have to either specify a DscOverride or give them via -S and -P. Sorry bestie, it can only do so much ๐Ÿ˜ญ
  • include codename .changes-filename โ€” includes in the specified distribution all packages found and suitable in the .changes file, applying override information and guessing all values that aren't given and guessable.
  • processincoming rulesetname [.changes-file] โ€” scans an incoming directory and processes the .changes files found there. If a filename is supplied, processing is limited to that file. rulesetname identifies which rule-set in conf/incoming determines which incoming directory to use and in what distributions to allow packages into. See the section about this file for more info ๐Ÿ‘‘
  • check [ codenames ] โ€” checks if all packages in the specified distributions have all the files they need properly registered. A lil wellness check for your repo ๐Ÿฉบ
  • checkpool [ fast ] โ€” checks if all files believed to be in the pool are actually still there and have the known md5sum. When fast is specified, md5sum is not checked. Speed over thoroughness, we respect the choice.
  • collectnewchecksums โ€” calculates all supported checksums for all files in the pool. (Versions prior to 3.3 only stored md5sums, 3.3 added sha1, 3.5 added sha256.) Evolution, honestly ๐ŸŒˆ
  • translatelegacychecksums โ€” removes the legacy files.db file after making sure all information is also found in the new checksums.db file. (Alternatively, you can call collectnewchecksums and remove the file on your own. DIY queen behavior ๐Ÿ’…)
  • rereference โ€” forgets which files are needed and recollects that information. A little memory wipe, a little fresh start โœจ
  • dumpreferences โ€” prints out which files are marked to be needed by whom.
  • dumpunreferenced โ€” prints a list of all files believed to be in the pool that aren't known to be needed. The lonely files ๐Ÿฅบ
  • deleteunreferenced โ€” removes all known files (and forgets them) in the pool that aren't marked to be needed by anything.
  • deleteifunreferenced [ filekeys ] โ€” removes the given files (and forgets them) in the pool if they're not marked to be used by anything. If no command line arguments are given, stdin is read and every line is treated as one filekey. This is mostly useful together with --keepunreferenced in conf/options, or in situations where you don't want to run deleteunreferenced, which removes all files eligible to be deleted with this command.
  • reoverride [ codenames ] โ€” reapplies the override files to the given distributions (or only parts thereof given by -A, -C or -T).
๐Ÿ™ˆ Note: only the control information is changed. Changing a section to a value that would cause another component to be guessed will not cause any warning. Sneaky like that.
  • redochecksums [ codenames ] โ€” re-adds the information about file checksums to the package indices. Usually the package's control information is created at inclusion time or imported from some remote source and isn't changed later โ€” this command modifies it to re-add missing checksum types. Only checksums already known are used. To update known checksums about files, run collectnewchecksums first. Order matters, bestie ๐ŸŽ€
  • dumptracks [ codenames ] โ€” prints out all information about tracked source packages in the given distributions.
  • retrack [ codenames ] โ€” recreates a tracking database for the specified distributions. This is a three-step situation: first, all files marked as part of a source package are set to unused. Then all files actually used are marked as such. Finally, tidytracks is called to remove everything no longer needed with the new info about used files. Beautiful little pipeline, honestly ๐Ÿฆ‹

(This behaviour, though a bit cumbersome, keeps even files only kept because of tracking mode keep and files not otherwise used but kept due to includechanges or its relatives. Before version 3.0.0, such files were lost when running retrack. We do not miss those days ๐Ÿ˜ญ)

removealltracks [ codenames ]

Wipes all the source package tracking information for the distributions you name. Like, all of it, gone, no take-backs ๐Ÿ’…

removetrack codename sourcename version

Removes the trackingdata of that one version of that one sourcepackage from that one distribution. It also nukes the references for every file that was used. Bye bestie ๐Ÿ’–

tidytracks [ codenames ]

Goes through all the source package tracking info for the distributions you list and checks it for files that are no longer meant to be kept. A little cleanup vibe check โœจ

copy destination-codename source-codename package[=version] ...

Copies packages from one distribution to another. The deets:

  • They're copied verbatim โ€” no override files are consulted, periodt.
  • Only components and architectures present in the source distribution get copied.
  • Want a specific version? Append = and the version to the name (no spaces, okay?). When no version is specified, the latest package version is the one that gets copied.

copysrc destination-codename source-codename source-package [versions]

Okay so this one looks at each package โ€” and yeah, "package" means every package as usual, be it dsc, deb or udeb โ€” in the distribution named by source-codename, and figures out the relevant source package for each one. Everything matching the given source-package name (and any version, if you gave one) gets copied over to the destination-codename distribution.

Same rules as ever: copied verbatim, no override files consulted, only components and architectures present in the source distribution. ๐Ÿซถ

copymatched destination-codename source-codename glob

Copies packages matching the given glob (check listmatched for how globs work, iykyk).

Copied verbatim, no override files consulted, only components and architectures present in the source distribution get copied.

copyfilter destination-codename source-codename formula

Copies packages matching the given formula (see listfilter). All versions if no version is specified. And yeah โ€” copied verbatim, no override files consulted, only components and architectures present in the source distribution.

move destination-codename source-codename package[=version] ...

Moves packages from one distribution to another. Note the move energy ๐Ÿ”ฅ

  • Moved verbatim โ€” no override files consulted.
  • Only components and architectures present in the source distribution get moved.
  • Version pinning works like copy: append = and the version to the name (no spaces). No version given โ†’ the latest package version is what moves.

movesrc destination-codename source-codename source-package [versions]

Same detective work as copysrc: it looks at every package (and yep, dsc, deb, udeb โ€” the whole crew) in the distribution named by source-codename and identifies the relevant source package for each. All packages matching the given source-package name (plus any version, if specified) get moved to the destination-codename distribution.

Moved verbatim, no override files consulted, only components and architectures present in the source distribution. ๐Ÿฆ‹

movematched destination-codename source-codename glob

Moves packages matching the given glob (see listmatched).

Moved verbatim, no override files consulted, only components and architectures present in the source distribution get moved.

movefilter destination-codename source-codename formula

Moves packages matching the given formula (see listfilter). All versions if no version is specified. Moved verbatim, no override files consulted, only components and architectures present in the source distribution.

restore codename snapshot packages...

restoresrc codename snapshot source-epackage [versions]

restorefilter destination-codename snapshot formula

restorematched destination-codename snapshot glob

These four are like the copy commands, but plot twist: they don't copy from another distribution โ€” they copy from a snapshot generated with gensnapshot. ๐ŸŽ€

Heads up bestie: this blindly trusts the contents of the files in your dists/ directory and does no checking. Trust falls only, apparently ๐Ÿ˜ญ

clearvanished

Removes all package databases that no longer appear in conf/distributions.

  • If --delete is specified, it will not stop if there are still packages left.
  • Even without --delete, it will unreference files still marked as needed by this target.
  • Use --keepunreferenced to not delete them if that was the last reference.

And don't forget the manual labor part: remove all exported package indices by hand. No cap, it's on you ๐Ÿซก

gensnapshot codename directoryname

Generates a snapshot of the distribution named by codename, living at dists/codename/snapshots/directoryname/, and references all needed files in the pool as needed by that snapshot. No Content files are generated, and no export hooks are run. Keep it simple, keep it chill โœจ

Big warning: there's currently no automated way to remove that snapshot again โ€” not even clearvanished will unlock the referenced files after the distribution itself vanished ๐Ÿซ  You have to remove the directory yourself and tell reprepro to unreferencesnapshot codename directoryname before deleteunreferenced will delete the files from the pool locked by this.

Wanna hit that snapshot with apt? Add something like this to your sources.list file:

deb method://as/without/snapshot codename/snapshots/name main

unreferencesnapshot codename directoryname

Removes all references generated by a genshapshot with the same arguments. This lets the next deleteunferenced call delete those files. (The indices in dists/ for the snapshot are not removed โ€” those stay exactly where they are.)

rerunnotifiers [ codenames ]

Runs all the external scripts specified in the Log: options of the distributions you specify. Go little scripts go ๐Ÿƒโ€โ™€๏ธ๐Ÿ’จ

build-needing codename architecture [ glob ]

Lists source packages (matching glob, if you gave one) that likely need a build on the given architecture.

So it lists all source packages in the given distribution that hit these conditions:

  • no binary package of the given architecture built from that version of the source
  • no .changes or .log file for the given architecture
  • an Architecture field including any, os-any (with os being the part before the hyphen in the architecture, or linux if there is no hyphen), or the architecture itself
  • and at least one package in the Binary field not yet available

If you use the term any instead of an architecture, all architectures are iterated, and the architecture gets printed as the fourth field in every line.

If the architecture is all, then only source packages with an Architecture field including all are considered (so, like, same deal as above with real architectures, except any does not suffice). Heads up: dpkg-dev << 1.16.1 does not both set any and all, so source packages building both architecture dependent and independent packages will never show up unless built with a new enough dpkg-source.

translatefilelists

Translates the file list cache within db/contents.cache.db into the new format used since reprepro 3.0.0.

Make sure you have at least half of the space of the current db/contents.cache.db file size available in that partition. Don't skip the space check bestie ๐Ÿ’€

translatelegacyreferences

Translates the references within db/references.db into the new format used since reprepro 5.4.0.

Make sure you have at least the same space as the current db/references.db file size available in that partition. Yep, the whole thing. Plan accordingly ๐ŸŒธ

flood distribution [architecture]

For each architecture of distribution (or just the one you specified), adds architecture all packages from other architectures โ€” same component or packagetype only โ€” under these conditions:

  • Packages are only upgraded, never downgraded.
  • If there's a package that is not architecture all, then architecture all packages of the same source from the same source version are preferred over those that have no such binary sibling.
  • Otherwise, the package with the highest version wins. ๐Ÿ‘‘

You can restrict which architectures are looked at for architecture all packages using -A, and which components/packagetypes get flooded using -C/-T, as usual.

Two main use cases, iykyk:

  1. You added a new architecture to a distribution and wanna copy all the architecture all packages onto it.
  2. You included some architecture all packages only for some architectures using -A (to avoid breaking the other architectures where the binary packages were still missing), and now you wanna copy it to those architectures where they're unlikely to break anything (because a newbinary is already available).

unusedsources [distributions]

Lists all source packages for which no binary package built from them is found. Lonely little sources ๐Ÿฅบ

sourcemissing [distributions]

Lists all binary packages for which no source package is found. The source package has to be in the same distribution โ€” but source packages only kept around by package tracking are enough. ๐Ÿ™ˆ

reportcruft [distributions]

Lists all source package versions that either have a source package and no longer a binary package, or binary packages left without a source package in the index. (Unless sourcemissing also lists packages where the source package is only in the pool due to enabled tracking but no longer in the index.) Cruft report, but make it fashion ๐Ÿ’…

sizes [ codenames ]

Lists the size of all packages in the distributions you specify โ€” or in all distributions if you don't specify any.

Each row has 4 numbers, each one being a number of bytes in a set of packages, and those sets are:

  1. the packages in this distribution (including anything only kept because of tracking)
  2. the packages only in this distribution (anything in this distribution and a snapshot of this distribution counts as only in this distribution)
  3. the packages in this distribution and its snapshots
  4. the packages only in this distribution or its snapshots

If more than one distribution is selected, it also lists a sum of those โ€” and in that sum, Only means only in the selected ones, not only in just one of the selected ones. Math but make it cute ๐Ÿงฎโœจ

  • repairdescriptions [ codenames ] โ€” looks for binary packages that only have a short description and tries to grab the long description from the .deb file (and also removes a possible Description-md5 in this case). ๐Ÿ’…

๐Ÿ› ๏ธ internal commands ๐Ÿ› ๏ธ

These are, like, hopefully never needed, but they allow manual intervention.

โš ๏ธ WARNING: Is is quite easy to get into an inconsistent and/or unfixable state.
  • _detect [ filekeys ] โ€” looks for the files whose filekey is given as an argument or as a line of input (when run without arguments), calculates their md5sum, and adds them to the list of known files. (Warning: this is a low level operation, no input validation or normalization is done.)
  • _forget [ filekeys ] โ€” like _detect but removes the given filekey from the list of known files. (Warning: this is a low level operation, no input validation or normalization is done.)
  • _listmd5sums โ€” prints a list of all known files and their md5sums.
  • _listchecksums โ€” prints a list of all known files and their recorded checksums.
  • _addmd5sums โ€” alias for the newer one.
  • _addchecksums โ€” adds information of known files (without any check done) in the strict format of _listchecksums output (i.e. don't dare to use a single space anywhere more than needed).
  • _dumpcontents identifier โ€” prints out all the stored information of the specified part of the repository. (Or, in other words, the content the corresponding Packages or Sources file would get.)
This command is deprecated and will be removed in a future version.
  • _addreference filekey identifier โ€” manually marks filekey as needed by identifier.
  • _addreferences identifier [ filekeys ] โ€” manually marks one or more filekeys as needed by identifier. If no command line arguments are given, stdin is read and every line is treated as one filekey.
  • _removereference identifier filekey โ€” manually removes the given mark that the file is needed by this identifier.
  • _removereferences identifier โ€” removes all references for what is needed by identifier.
  • __extractcontrol .deb-filename โ€” looks at what reprepro believes to be the content of the control file of the specified .deb file.
  • __extractfilelist .deb-filename โ€” looks at what reprepro believes to be the list of files of the specified .deb file.
  • _fakeemptyfilelist filekey โ€” inserts an empty filelist for filekey. This is an evil hack around broken .deb files that cannot be read by reprepro.
  • _addpackage codenam filename packages... โ€” adds packages from the specified filename to the part specified by -C, -A and -T of the specified distribution. Very strange things can happen if you use it improperly.
  • __dumpuncompressors โ€” lists what compression formats can be uncompressed and how.
  • __uncompress format compressed-file uncompressed-file โ€” uses builtin or external uncompression to uncompress the specified file of the specified format into the specified target.
  • _listcodenames โ€” prints the codenames of all configured distributions, one per line.
  • _listconfidentifiers identifier [ distributions... ] โ€” prints, one per line, all identifiers of subdatabases as derived from the configuration. If a list of distributions is given, only identifiers of those are printed.
  • _listdbidentifiers identifier [ distributions... ] โ€” prints, one per line, all identifiers of subdatabases in the current database. This will be a subset of the ones printed by _listconfidentifiers or most commands, but clearvanished will refuse to run, and depending on the database compatibility version, will include all those if reprepro was run since the config was last changed.

๐Ÿฆ‹ CONFIG FILES ๐Ÿฆ‹

reprepro uses three config files, which are searched in the directory specified with --confdir or in the conf/ subdirectory of the basedir.

If a file options exists, it is parsed line by line. Each line can be the long name of a command line option (without the --) plus an argument, where possible. Those are handled as if they were command line options given before (and thus lower priority than) any other command line option, and also lower priority than any environment variable.

To allow command line options to override options-file options, most boolean options also have a corresponding form starting with --no.

(The only exception is when the path to look for config files changes: the options file will only be opened once, and of course before any options within the options file are parsed.)

The file distributions is always needed and describes what distributions to manage, while updates is only needed when syncing with external repositories, and pulls is only needed when syncing with repositories in the same reprepro database.

The last three are in the format control files in Debian are in, i.e. paragraphs separated by empty lines consisting of fields. Each field consists of a fieldname, followed by a colon, possible whitespace and the data. A field ends with a newline not followed by a space or tab.

Lines starting with # as first character are ignored, while in other lines the # character and everything after it till the newline character are ignored.

A paragraph can also consist of only a single field !include: which causes the named file (relative to confdir unless starting with ~/, +b/, +c/ or /) to be read as if it was found at this place.

Each of the three files, or a file included as described above, can also be a directory, in which case all files it contains with a filename ending in .conf and not starting with . are read.

๐Ÿ“ conf/distributions ๐Ÿ“

  • Codename โ€” this required field is the unique identifier of a distribution and is used as a directory name within dists/. It is also copied into the Release files.

Note that this name is not supposed to change. You most likely never ever want a name like testing or stable here (those are suite names and supposed to point to another distribution later).

  • Suite โ€” this optional field is simply copied into the Release files. In Debian it contains names like stable, testing or unstable. To create symlinks from the Suite to the Codename, use the createsymlinks command of reprepro.
  • FakeComponentPrefix โ€” if this field is present, its argument is added โ€” separated by a slash โ€” before every Component written to the main Release file (unless the component already starts with it), and removed from the end of the Codename and Suite fields in that file. Also, if a component starts with it, its directory in the dists dir is shortened by this.

So

 Codename: bla/updates
 Suite: foo/updates
 FakeComponentPrefix: updates
 Components: main bad

will create a Release file with

 Codename: bla
 Suite: foo
 Components: updates/main updates/bad

in it, but otherwise nothing is changed, while

 Codename: bla/updates
 Suite: foo/updates
 FakeComponentPrefix: updates
 Components: updates/main updates/bad

will also create a Release file with

 Codename: bla
 Suite: foo
 Components: updates/main updates/bad

but the packages will actually be in the components updates/main and updates/bad, most likely causing the same file using duplicate storage space.

This makes the distribution look more like Debian's security archive, thus work around problems with apt's workarounds for that.

  • AlsoAcceptFor โ€” a list of distribution names. When a .changes file is told to be included into this distribution with the include command and the distribution header of that file is neither the codename, nor the suite name, nor any name from the list, a wrongdistribution error is generated. The processincoming command will also use this field, see the description of Allow and Default from the conf/incoming file for more information.
  • Version โ€” this optional field is simply copied into the Release files.
  • Origin โ€” this optional field is simply copied into the Release files.
  • Label โ€” this optional field is simply copied into the Release files.
  • NotAutomatic โ€” this optional field is simply copied into the Release files. (The value is handled as an arbitrary string, though anything but yes does not make much sense right now.)
  • ButAutomaticUpgrades โ€” this optional field is simply copied into the Release files. (The value is handled as an arbitrary string, though anything but yes does not make much sense right now.)
  • Description โ€” this optional field is simply copied into the Release files.
  • Changelogs โ€” this optional field is simply copied into the Release files. It is used to signal apt's changelog command where to find package changelogs. Example:
 Changelogs:
https://apt.postgresql.org/pub/repos/apt/pool/@CHANGEPATH@.changelog

See apt.conf(5) for how @CHANGEPATH@ is expanded by apt.

  • Architectures โ€” this required field lists the binary architectures within this distribution, and if it contains source (i.e. if there is an item source in this line this Distribution has source. All other items specify things to be put after "binary-" to form directory names and be checked against "Architecture:" fields.)

This will also be copied into the Release files. (With exception of the source item, which will not occur in the topmost Release file whether it is present here or not.)

  • Components โ€” this required field lists the component of a distribution. See GUESSING for rules which component packages are included into by default. This will also be copied into the Release files.
  • DDebComponents โ€” list of components containing .ddebs.
  • UDebComponents โ€” components with a debian-installer subhierarchy containing .udebs. (E.g. simply "main".)
  • Update โ€” when this field is present, it describes which update rules are used for this distribution. There also can be a magic rule minus ("-"), see below.

๐Ÿ’– Pull ๐Ÿ’–

okay so when this field shows up, it's telling you which pull rules this distribution uses. Pull rules are like Update rules, except they get their stuff from other distributions and not from external sources. for the deets, go look at conf/pulls. iykyk ๐Ÿซถ


๐Ÿ” SignWith ๐Ÿ”

when this field is present, a Release.gpg file will be generated. here's the tea on the values:

  • if the value is "yes" or "default", the default key of gpg is used.
  • if the field starts with an exclamation mark ("!"), the given script is executed to do the signing.
  • otherwise, the value gets handed to libgpgme to figure out which key to use.

ngl, if you're having signing problems, try this to see how gpg might interpret the value:

gpg --list-secret-keys value

if that command lists no keys โ€” or like, multiple ones ๐Ÿ˜ญ โ€” try to find some other value (like the keyid) that gpg can more easily associate with a unique key. slay.

if this key has a passphrase, you need to use gpg-agent or the insecure option --ask-passphrase. bestie, i said insecure, so be careful ๐Ÿ’€

a '!' hook script is looked for in the confdir, unless it starts with ~/, ./, +b/, +o/, +c/ or /. it gets three command line arguments:

  1. the filename to sign
  2. an empty argument or the filename to create with an inline signature (i.e. InRelease)
  3. an empty argument or the filename to create a detached signature (i.e. Release.gpg)

the script may generate no Release.gpg file if it chooses to (in that case the repository will look like unsigned for older clients), but generating empty files is not allowed. reprepro waits for the script to finish and will abort the exporting of the distribution this signing is part of unless the script returns normally with exit code 0. and put a space after ! โ€” it's recommended to avoid incompatibilities with possible future extensions โœจ


๐Ÿ“ฆ DebOverride ๐Ÿ“ฆ

when this field is present, it describes the override file used when including .deb files.

๐Ÿง UDebOverride ๐Ÿง

when this field is present, it describes the override file used when including .udeb files.

๐Ÿ“œ DscOverride ๐Ÿ“œ

when this field is present, it describes the override file used when including .dsc files.


๐Ÿ—‚๏ธ DebIndices, UDebIndices, DscIndices ๐Ÿ—‚๏ธ

these pick what kind of Index files to export. the first part describes what the Index file shall be called. the second argument determines the name of a Release file to generate โ€” or not to generate if it's missing. then comes at least one of ".", ".gz", ".xz" or ".bz2", specifying whether to generate uncompressed output, gzipped output, bzip2ed output, or any combination of those. (heads up: bzip2 is only available when compiled with bzip2 support, so it might not be available if you compiled it on your own โ€” same deal for xz and liblzma ๐Ÿซ ) and if an argument not starting with a dot follows, it will be executed after all index files are generated (check the examples for what argument this gets).

the default is:

DebIndices: Packages Release . .gz
UDebIndices: Packages . .gz
DscIndices: Sources Release .gz

โš™๏ธ ExportOptions โš™๏ธ

options to modify how โ€” and whether โ€” exporting is done:

  • noexport โ€” never export this distribution. meaning there'll be no directory below dists/ generated, and the distribution is only useful for copying packages to other distributions.
  • keepunknown โ€” ignore unknown files and directories in the exported directory. this is currently the only available option and the default, but that might change in the future, so you can already request it explicitly. love that for us ๐Ÿ’…

๐Ÿ“‹ Contents ๐Ÿ“‹

turns on creation of Contents files listing all the files inside the binary packages of a distribution. it's quite slow โ€” you have been warned ๐Ÿ˜ญ

in earlier versions, the first argument was a rate at which to extract file lists. as this did not work and was no longer easily possible after some factorisation, it's no longer supported. rip.

the arguments of this field are a space separated list of options:

  • if there's a udebs keyword, .udebs are also listed (in a file called uContents-architecture).
  • if there's a nodebs keyword, .debs are not listed. (only useful together with udebs)
  • if there's at least one of the keywords ., .gz, .xz and/or .bz2, the Contents files are written uncompressed, gzipped and/or bzip2ed instead of only gzipped.
  • if there's a percomponent, then one Contents-arch file per component is created.
  • if there's an allcomponents, then one global Contents-arch file is generated.
  • if both are given, both are created. if neither is specified, percomponent is taken as default (earlier versions had other defaults ๐Ÿ‘€).
  • the switches compatsymlink or nocompatsymlink (only possible if allcomponents was not specified explicitly) control whether a compatibility symlink is created so old versions of apt-file looking for the component independent filenames at least see the contents of the first component.

unless allcomponents is given, compatsymlinks currently is the default, but that will change in some future (current estimate: after wheezy was released). so like, get ready for that ๐Ÿฆ‹


๐Ÿ—๏ธ ContentsArchitectures ๐Ÿ—๏ธ

limits generation of Contents files to the architectures given. if this field isn't there, all architectures are processed. an empty field means no architectures are processed โ€” thus not very useful ๐Ÿ™ˆ

๐ŸŽ€ ContentsComponents ๐ŸŽ€

limits what components are processed for the Contents-arch files to the components given. if this field isn't there, all components are processed. an empty field is equivalent to specifying nodebs in the Contents field, while a non-empty field overrides a nodebs there. icon behavior โœจ

๐Ÿงš ContentsUComponents ๐Ÿงš

limits what components are processed for the uContents files to the components given. if this field isn't there and there is the udebs keyword in the Contents field, all .udebs of all components are put in the uContents.arch files. if this field isn't there and there's no udebs keyword in the Contents field, no uContents-arch files are generated at all. a non-empty field implies generation of uContents-arch files (just like the udebs keyword in the Contents field), while an empty one causes no uContents-arch files to be generated. periodt.


๐Ÿซถ Uploaders ๐Ÿซถ

specifies a file (relative to confdir if not starting with ~/, +b/, +c/ or /) to specify who is allowed to upload packages. without this there are no limits, and this file can be ignored via --ignore=uploaders. see the section UPLOADERS FILES below ๐Ÿ’œ


๐Ÿ” Tracking ๐Ÿ”

enables the (experimental) tracking of source packages. the argument list needs to contain exactly one of the following:

  • keep โ€” keeps all files of a given source package, until that is deleted explicitly via removetrack. this is currently the only possibility to keep older packages around when all indices contain newer files.
  • all โ€” keep all files belonging to a given source package until the last file of it is no longer used within that distribution.
  • minimal โ€” remove files no longer included in the tracked distribution. (remove changes, logs and includebyhand files once no file is in any part of the distribution.)

and any number of the following (or none):

  • includechanges โ€” add the .changes file to the tracked files of a source package. thus it is also put into the pool.
  • includebyhand โ€” add byhand and raw-* files to the tracked files and thus in the pool.
  • includebuildinfos โ€” add buildinfo files to the tracked files and thus in the pool.
  • includelogs โ€” add log files to the tracked files and thus in the pool. (note that putting log files in changes files is a reprepro extension not found in normal changes files ๐Ÿ‘€)
  • embargoalls โ€” not yet implemented.
  • keepsources โ€” even when using minimal mode, do not remove source files until no file is needed any more.
  • needsources โ€” not yet implemented.

๐Ÿ”ข Limit ๐Ÿ”ข

set this to an integer greater than one to keep multiple versions of a package per distribution, architecture, component, and type. all old package versions that exceed this limit will be removed or archived (see the Archive option) when a new package version is added. if the number is zero or negative, all package versions will be kept. by default only one package version will be kept. main character energy fr fr ๐Ÿ‘‘

๐Ÿ—„๏ธ Archive ๐Ÿ—„๏ธ

specify a codename which must be declared before (to avoid loops). when packages exceed the version count limit (specified in Limit), these packages will be moved to the specified distribution instead of being removed. no losses, only relocation ๐Ÿฆ‹


๐Ÿ“ Log ๐Ÿ“

specify a file to log additions and removals of this distribution into and/or external scripts to call when something is added or removed. the rest of the Log: line is the filename, and every following line (as usual, they have to begin with a single space) is the name of a script to call.

the name of the script may be preceded with options of the form --type=(dsc|deb|udeb), --architecture=name or --component=name to only call the script for some parts of the distribution. a script with argument --changes is called when a .changes file was accepted by include or processincoming (and with other arguments). both type of scripts can have a --via=command specified, in which case it is only called when caused by reprepro command command.

for information on how it's called and some examples, take a look at manual.html in reprepro's source or /usr/share/doc/reprepro/.

if the filename for the log files does not start with a slash, it's relative to the directory specified with --logdir; the scripts are relative to --confdir unless starting with ~/, +b/, +c/ or /. got it? slay ๐Ÿ’–


โณ ValidFor โณ

if this field exists, a Valid-Until field is put into generated Release files for this distribution with a date as much in the future as the argument specifies.

the argument has to be a number followed by one of the units d, m or y, where d means days, m means 31 days and y means 365 days. so ValidFor: 1m 11 d causes the generation of a Valid-Until: header in Release files that points 42 days into the future. math! we love her ๐Ÿงฎโœจ

  • ReadOnly โ€” no touching, bestie ๐Ÿ’…. This disallows all modifications of this distribution or its directory in dists/codename (with the exception of snapshot subdirectories).
  • ByHandHooks โ€” this one specifies hooks to call for handling byhand/raw files by processincoming (and in future versions perhaps by include). Each line consists of 4 arguments: a glob pattern for the section (classically byhand, though Ubuntu uses raw-*), a glob pattern for the priority (not usually used), and a glob pattern for the filename. The 4th argument is the script to be called when all of the above match. That script gets 5 arguments: the codename of the distribution, the section (usually byhand), the priority (usually only -), the filename in the changes file, and the full filename (with processincoming in the secure TempDir).
  • Signed-By โ€” optional field, simply copied into the Release files. It's used to tell apt which keys to trust for this Release in the future. (See SignWith for how to tell reprepro whether and how to sign.) ๐Ÿ”

๐Ÿ—‚๏ธ conf/updates ๐Ÿ—‚๏ธ

  • Name โ€” the name of this update-upstream, as it can be used in the Update field in conf/distributions.
  • Method โ€” a URI as one could also give it apt, e.g. http://ftp.debian.de/debian, which is simply given to the corresponding apt-get method. (So either apt-get has to be installed, or you have to point with --methoddir to a place where such methods are found.)
  • Fallback โ€” (still experimental ๐Ÿ‘€) a fallback URI, where all files are tried that failed the first one. They're given to the same method as the previous URI (e.g. both http://), and the fallback-server must have everything at the same place. No recalculation is done, but single files are just retried from this location.
  • Config โ€” can contain any number of lines, each in the format apt-get --option would expect. (Multiple lines โ€” as always โ€” marked with leading spaces.) For example:
Config: Acquire::Http::Proxy=http://proxy.yours.org:8080
  • From โ€” the name of another update rule this rule derives from. The rule containing the From may not contain Method, Fallback or Config. All other fields are used from the rule referenced in From, unless found in this one containing the From. The rule referenced in From may itself contain a From. Reprepro will only assume two remote index files are the same, if both get their Method information from the same rule.
  • Suite โ€” the suite to update from. If this is not present, the codename of the distribution using this one is used. Also */whatever is replaced by <codename>/whatever.
  • Components โ€” the components to update. Each item can be either the name of a component or a pair of an upstream component and a local component separated with > (e.g. main>all contrib>all non-free>notall). If this field is not there, all components from the distribution to update are tried. An empty field means no source or .deb packages are updated by this rule, but only .udeb packages, if there are any. A rule might list components not available in all distributions using this rule. In this case unknown components are silently ignored. (Unless you start reprepro with the --fast option, it will warn about components unusable in all distributions using that rule. As exceptions, unusable components called none are never warned about, for compatibility with versions prior to 3.0.0 where an empty field had a different meaning.)
  • Architectures โ€” the architectures to update. If omitted, all from the distribution to update from. (As with components, you can use > to download from one architecture and add into another one. This only determines in which Package list they land; it neither overwrites the Architecture line in its description, nor the one in the filename determined from this one. In other words, it is no really useful without additional filtering.)
  • UDebComponents โ€” like Components but for the udebs.
  • VerifyRelease โ€” download the Release.gpg file and check if it is a signature of the Release file with the key given here. (In the format gpg --with-colons --list-key prints it, i.e. the last 16 hex digits of the fingerprint.) Multiple keys can be specified by separating them with a | sign. Then finding a signature from one of them will suffice. To allow revoked or expired keys, add a ! behind a key. (But to accept such signatures, the appropriate --ignore is also needed.) To also allow subkeys of a specified key, add a + behind a key.
  • IgnoreRelease: yes โ€” if this is present, no InRelease or Release file will be downloaded and thus the md5sums of the other index files will not be checked. ๐Ÿ™ˆ
  • GetInRelease: no โ€” if this is present, no InRelease file is downloaded but only Release (and Release.gpg) are tried.
  • Flat โ€” if this field is in an update rule, it is supposed to be a flat repository, i.e. a repository without a dists dir and no subdirectories for the index files. (If the corresponding sources.list line has the suite end with a slash, then you might need this one.) The argument for the Flat: field is the Component to put those packages into. No Components or UDebComponents fields are allowed in a flat update rule. If the Architecture field has any > items, the part left of the > is ignored. For example, the sources.list line
deb http://cran.r-project.org/bin/linux/debian etch-cran/

would translate to

Name: R
Method: http://cran.r-project.org/bin/linux/debian
Suite: etch-cran
Flat: whatevercomponentyoudlikethepackagesin
  • IgnoreHashes โ€” tells reprepro to not check the listed hashes in the downloaded Release file (and only in the Release file). Possible values are currently md5, sha1 and sha256. Note that this does not speed anything up in any measurable way. The only reason to specify this is if the Release file of the distribution you want to mirror from uses a faulty algorithm implementation. Otherwise you will gain nothing and only lose security. ๐Ÿšจ
  • FilterFormula โ€” can be a formula to specify which packages to accept from this source. The format misuses the parser intended for Dependency lines. To get only architecture all packages use architecture (== all), to get only at least important packages use priority (==required) | priority (==important). See the description of the listfilter command for the semantics of formulas.
  • FilterList, FilterSrcList โ€” these two options each take at least two arguments: the first argument is the fallback (default) action. All following arguments are treated as file names of lists. The filenames are considered to be relative to --confdir, if not starting with ~/, +b/, +c/ or /. Each list file consists of lines with a package name followed by whitespace followed by an action. Each list may only contain a single line for a given package name. The action to be taken is the action specified by the first file mentioning that package. If no list file mentions a package, the fallback action is used instead. This format is inspired by dpkg --get-selections before multiarch, and the names of the actions likely only make sense if you imagine the file to be the output of this command of an existing system. For each package available in the distribution to be updated from/pulled from, this action is determined and affects the current decision what to do to the target distribution. (Only after all update/pull rules for a given target distribution have been processed is something actually done.) The possible action keywords are:
    • install โ€” mark the available package to be added to the target distribution unless the same version or a higher version is already marked as to be added/kept. (Note that without a prior delete rule (-) or supersede action, this will never downgrade a package, as the already existing version is marked to be kept.)
    • upgradeonly โ€” like install but will not add new packages to a distribution.
    • supersede โ€” unless the current package version is higher than the available package version, mark the package to be deleted in the target distribution. (Useful to remove packages in add-on distributions once they reached the base distribution.)
    • deinstall or purge โ€” ignore the newly available package.
    • warning โ€” print a warning message to stderr if a new package/newer version is available. Otherwise ignore the new package (like with deinstall or purge).
    • hold โ€” the new package is ignored, but every previous decision to downgrade or delete the package in the target distribution is reset.
    • error โ€” abort the whole upgrade/pull if a new package/newer version is available.
    • = version โ€” if the candidate package has the given version, behave like install. Otherwise continue as if this list file did not mention this package (i.e. look in the remaining list files or use the fallback action). Only one such entry per package is currently supported and the version is currently compared as string.

If there is both FilterList and FilterSrcList then the first is used for .deb and .udeb and the second for .dsc packages.

If there is only FilterList that is applied to everything.

If there is only FilterSrcList that is applied to everything, too, but the source package name (and source version) is used to do the lookup.

  • OmitExtraSourceOnly โ€” controls whether source packages that have Extra-Source-Only set get ignored when reprepro is grabbing source packages. If this field isn't there, or if it's set to true, those source packages get ignored, periodt. But if you set it to no or false, they're also candidates โ€” as long as no other filter shuts them out first. (Heads up: the default is true, but that's probably gonna change once reprepro supports multiple versions of a package or finds some other way to keep source packages around.)
  • ListHook โ€” if you give this one, it gets executed for every downloaded index file. It receives the downloaded list as its first argument, plus a filename that'll be used instead of it. Like, ListHook: /bin/cp technically works but does absolutely nothing โ€” iconic but useless, we love that for her. ๐Ÿ™ˆ

If a file gets read multiple times, it gets processed multiple times too, with these env vars set: REPREPRO_FILTER_CODENAME, REPREPRO_FILTER_PACKAGETYPE, REPREPRO_FILTER_COMPONENT and REPREPRO_FILTER_ARCHITECTURE, all pointing at where this file will be added โ€” and REPREPRO_FILTER_PATTERN set to the name of the update rule causing it. ๐Ÿ’…

  • ListShellHook โ€” same energy as ListHook, except the whole argument gets handed to the shell as an argument, and the input and output file are stdin and stdout.

i.e.:

ListShellHook: cat

works but does nothing except be a useless use of a shell and cat, whereas:

ListShellHook: grep-dctrl -X -S apt -o -X -S dpkg || [ $? -eq 1 ]

will limit the update rule to packages from the specified source packages. now THAT'S a slay โœจ

  • DownloadListsAs โ€” the arguments here tell reprepro which index files to download.

Allowed values are ., .gz, .bz2, .lzma, .xz, .diff, force.gz, force.bz2, force.lzma, force.xz, and force.diff.

Reprepro tries the first supported variant in the list you give it: only compressions that were compiled in, or for which an uncompressor was found, actually get used. And unless the value starts with force., it's only tried if it's found in the Release or InRelease file. ๐Ÿ‘‘

The default value is .diff .xz .lzma .bz2 .gz . โ€” i.e. download Packages.diff if it's listed in the Release file, otherwise (or if it's not usable) download .xz if it's listed in the Release file and there's a way to uncompress it, then .lzma if usable, then .bz2 if usable, then .gz, and finally uncompressed. ๐Ÿซถ

Warning bestie: there is literally no way to see if an uncompressed variant of the file is available (because the Release file always lists their checksums, even if the file isn't there ๐Ÿ˜ญ). So putting . anywhere except as the last argument can mean trying to download a file that does not exist. Don't do that to yourself.

Together with IgnoreRelease, reprepro will download the first one in this list that could be unpacked (i.e. force is always assumed) and the default value is .gz .bzip2 . .lzma .xz. โญ


๐Ÿฆ‹ conf/pulls ๐Ÿฆ‹

This file is where the rules live for pulling packages from one distribution to another. Yes, you could also do this with update rules using the file or copy method and using the exported indices of that other distribution โ€” but this way is faster. ๐Ÿš€ It also ensures the current files are used and no copies are made. (Which also leads to the limitation that pulling from one component to another is not possible โ€” sorry babe, that's just how it is.)

Each rule consists out of the following fields:

  • Name โ€” the name of this pull rule, as it can be used in the Pull field in conf/distributions. ๐Ÿ’–
  • From โ€” the codename of the distribution to pull packages from.
  • Components โ€” the components of the distribution to get from.

If this field is not there, all components from the distribution to update are tried.

A rule might list components that aren't available in all distributions using this rule. In that case, unknown components are silently ignored. (Unless you start reprepro with the --fast option, in which case it'll warn about components unusable in all distributions using that rule. As an exception, unusable components called none are never warned about, for compatibility with versions prior to 3.0.0 where an empty field had a different meaning.) ๐Ÿ™ˆ

  • Architectures โ€” the architectures to update. If omitted, all from the distribution to pull from. As in conf/updates, you can use > to download from one architecture and add into another one. (And again, that's only useful with filtering to avoid packages not architecture all migrating.) ๐Ÿ’…
  • UDebComponents โ€” like Components but for the udebs. ๐ŸŽ€
  • FilterFormula
  • FilterList
  • FilterSrcList โ€” the same as with update rules. โœจ

๐ŸŽ€ OVERRIDE FILES ๐ŸŽ€

Okay so override files, bestie โ€” they let you rewrite the fields of a package without touching the package itself. Iconic. The format is supposed to resemble the extended ftp-archive format, and specifically it's this:

packagename field name new value

Like, for example:

kernel-image-2.4.31-yourorga Section protected/base
kernel-image-2.4.31-yourorga Priority standard
kernel-image-2.4.31-yourorga Maintainer That's me <me@localhost>
reprepro Priority required

The way it works is: all fields of a given package get replaced by the new value you specified in the override file โ€” with one little exception, the special fields starting with a dollar sign ($), those are different vibes entirely (more on them below ๐Ÿ’…).

So the field name is compared case-insensitive, but it gets copied into the output in exactly the form it appears in the override file. So yeah โ€” keep to the exact case it's normally found in index files, because some other tool out there might get confused otherwise. Not me being dramatic, that's just how it is. ๐Ÿซถ

Also, the Section header does more than just get copied (unless -S is supplied, that is) โ€” it's also used to guess the component (unless -C is there). Sneaky little multitasker.

Some values are straight-up forbidden, bestie โ€” like Package, Filename, Size or MD5sum. Using those would severely confuse reprepro, and we do NOT want to confuse the icon. ๐Ÿ’€

--- โœจ ---

As an extension, reprepro also supports patterns instead of packagenames. So if a package name contains *, [ or ?, it's considered a pattern and gets applied to each package that is not matched by any non-pattern override, nor by any previous pattern. (Order matters, iykyk.)

Fieldnames starting with a dollar ($) are not placed in the exported control data โ€” they have special meaning instead. Unknown ones are loudly ignored. ๐Ÿ™ˆ The special fields are:

  • $Component โ€” includedeb, includedsc, include and processincoming will put the package in the component given as value (unless it's itself overridden with -C). Note that the proper way to specify the component is by setting the section field, and using this extension will most likely confuse people and/or tools.
  • $Delete โ€” the value is treated as a fieldname, and fields of that name are removed. (This way you can remove fields previously added without removing and re-adding the package. And fields already included in the package can be removed, too.) Slay.

conf/incoming

Every chunk here is a rule set for the processincoming command. The possible fields are:

  • Name โ€” the name of the rule-set, used as the argument to the scan command to specify which rule to use.
  • IncomingDir โ€” the name of the directory to scan for .changes files.
  • TempDir โ€” a directory where the files listed in the processed .changes files are copied into before they're read. Fun optimization: you can avoid some copy operations by placing this directory within the same mount point the pool hierarchy is (at least partially) in. ๐Ÿ’…
  • LogDir โ€” a directory where .changes files, .log files, .buildinfo files and otherwise unused .byhand files are stored upon procession.
  • Allow โ€” each argument is either a pair name1>name2 or simply name, which is short for name>name. Each name2 must identify a distribution โ€” either by being Codename, a unique Suite, or a unique AlsoAcceptFor from conf/distributions. Each upload has each item in its Distribution: header compared, first to last, with each name1 in the rules, and it's put in the first one accepting this package. e.g.:
Allow: local unstable>sid

or

Allow: stable>security-updates stable>proposed-updates

(Note that this only makes sense if Multiple is set to true, or if there are people only allowed to upload to proposed-updates but not to security-updates.)

  • Default distribution โ€” every upload not put into any other distribution because of an Allow argument is put into distribution, if that accepts it.
  • Multiple โ€” old form of Options: multiple_distributions.
  • Options โ€” a list of options:
    • multiple_distributions โ€” allow including an upload in multiple distributions. If a .changes file lists multiple distributions, then reprepro will start with the first name given, check all Accept and Default options till it finds a distribution this upload can go into. If this found no distribution, or if this option was given, reprepro will then do the same with the second distribution name given in the .changes file, and so on.
    • limit_arch_all โ€” if an upload contains binaries from some architecture and architecture-all packages, the architecture-all packages are only put into the architectures within this upload. Useful to combine with the flood command.
  • Permit โ€” a list of options to allow things otherwise causing errors:
    • unused_files โ€” don't stop with an error if there are files listed in the .changes file that don't belong to any package in it.
    • older_version โ€” ignore a package not added because there already is a strictly newer version available, instead of treating this as an error.
    • unlisted_binaries โ€” don't abort with an error if a .changes file contains .deb files that aren't listed in the Binaries header.
  • Cleanup options โ€” a list of options to cause more files in the incoming directory to be deleted:
    • unused_files โ€” if there's unused_files in Permit, then also delete those files when the package is deleted after successful processing.
    • unused_buildinfo_files โ€” if .buildinfo files of processed .changes files aren't used (neither stored by LogDir nor with Tracking: includebuildinfos), then delete them from the incoming dir. (This option has no additional effect if unused_files is already used.)
    • on_deny โ€” if a .changes file is denied processing because of missing signatures or allowed distributions to be put in, delete it and all the files it references.
    • on_error โ€” if a .changes file causes errors while processing, delete it and the files it references.
Okay bestie, real talk โš ๏ธ โ€” allowing cleanup in publicly accessible incoming queues allows a denial of service by sending in .changes files that delete other people's files before they're completed. Especially when .changes files are handled directly (e.g. by inoticoming). Be careful out there. ๐Ÿ˜ญ
  • MorgueDir โ€” if files are to be deleted by Cleanup, they're instead moved to a subdirectory of the directory given as the value to this field. This directory has to be on the same partition as the incoming directory, and files are moved (i.e. owner and permission stay the same) and never copied. ๐Ÿฆ‹

๐Ÿ’… UPLOADERS FILES ๐Ÿ’…

Okay bestie, so this whole file is set by the Uploaders header in the distribution definition (the one we talked about earlier, remember? ๐Ÿซถ). What it does is describe what key a .changes file has to be signed with to be let into that distribution. Like a bouncer at the club, but for signatures. โœจ

Empty lines? Ignored. Lines starting with a hash? Also ignored. Every other line has to be one of the following nine forms, or an include directive. Nine, bestie, count 'em:

  • allow condition by anybody โ€” this one lets literally everyone upload packages matching condition. No key needed, no vibes checked, come on in ๐Ÿ’€
  • allow condition by unsigned โ€” lets through everything matching that has no pgp/gpg header. Yeah. Unsigned. Iconic of you to allow that.
  • allow condition by any key โ€” lets through everything matching with any valid signature in or
  • allow condition by key key-id โ€” lets through everything matching that's signed by this key-id (and it's got to be written with no spaces at all, fr fr). If the key-id ends with a + (plus), then a signature with a subkey of this primary key also suffices. Slay, subkeys get in too ๐Ÿ’…
  • allow condition by group groupname โ€” lets in every member of the group called groupname

The key-id has to be a suffix of the id that libgpgme uses to identify this key โ€” i.e. a bunch of hex digits from the end of the fingerprint of the key, but not more than what libgpgme uses. (The max number should be what gpg --list-key --with-colons prints, and as of the time of this writing that's at most 16 hex-digits. History, bestie ๐Ÿ“œ)

Groups can be manipulated with these โ€” yes, these are also part of the nine, they've got their own little family:

  • group groupname add key-id โ€” adds a key-id (see above for the details, go look ๐Ÿ‘€) to this group
  • group groupname contains groupname โ€” adds a whole entire group to a group. Group-ception, we love it ๐ŸŒ€

And to avoid warnings in incomplete config files there's also:

  • group groupname empty โ€” declares a group has no members (this avoids the warnings that it is used without those)
  • group groupname unused โ€” declares that a group is not yet used (this avoids the warnings that it is not used)

A line starting with include makes the rest of the line get interpreted as a filename โ€” that file gets opened and processed before the rest of the file is processed. Sneaky little prequel moment ๐ŸŽ€


๐ŸŒˆ The conditions that are currently supported ๐ŸŒˆ

These are the actual vibes you can match on, bestie:

  • * โ€” which means any package. The wildcard of wildcards. Main character energy ๐Ÿ‘‘
  • source 'name' โ€” means any package with that source name. ('*', '?' and '[..]' are treated as in shell wildcards, so go wild)
  • sections 'name'('|'name')* โ€” matches an upload in which each section matches one of the names given. Heads up tho: because upload conditions are checked very early, this is the section listed in the .changes file, not the one from the override file. (But this might change in the future โ€” if you have the need for one behavior or the other, let me know ๐Ÿ˜ญ)
  • sections contain 'name'('|'name')* โ€” the same thing, except not all sections must be from the given set; at least one source or binary package needs to have one of those given. Loosened the grip, we stan ๐ŸŒธ
  • binaries 'name'('|'name')* โ€” matches an upload in which each binary (type deb or udeb) matches one of the names given
  • binaries contain 'name'('|'name')* โ€” again, only at least one instead of all is required
  • architectures 'architecture'('|'name')* โ€” matches an upload in which each package has only architectures from the given set. source and all are treated as unique architectures. Wildcards are not allowed here, so don't even try it ๐Ÿ™ˆ
  • architectures contain 'architecture'('|'architecture')* โ€” again only at least one instead of all is required
  • byhand โ€” matches an upload with at least one byhand file (i.e. a file with section byhand or raw-something โ€” you know the type)
  • byhand 'section'('|'section')* โ€” matches an upload with at least one byhand file and all byhand files having a section listed in the list of given sections. (i.e. byhand 'byhand'|'raw-*' is currently the same as just plain byhand โ€” cute how that works)
  • distribution 'codename' โ€” means any package when it is to be included in codename. And since the uploaders file is given by distribution, this is only useful for reusing a complex uploaders file for multiple distributions. Efficiency queen ๐Ÿงš

๐Ÿฆ‹ Combining conditions (this is where it gets good) ๐Ÿฆ‹

Putting not in front of a condition inverses its meaning. Example time, watch this:

allow not source 'r*' by anybody

That means anybody may upload packages which source name does not start with an r. See? Inverted. Flip it and reverse it ๐Ÿ’ซ

Multiple conditions can be connected with and and or, and or binds stronger (but both of them are weaker than not). So this:

allow source 'r*' and source '*xxx' or source '*o' by anybody

is equivalent to this:

allow source 'r*xxx' by anybody
allow source 'r*o' by anybody

Literally the same thing, just spelled differently. Math is mathing ๐Ÿ”ฅ


(Other conditions will follow once somebody tells me what restrictions are useful. Currently planned is only something for architectures.) ๐Ÿ‘€โœจ

๐Ÿ’€ ERROR IGNORING ๐Ÿ’€

okay so bestie, sometimes your archive is a little messy and you need reprepro to chill instead of absolutely losing it. With --ignore on the command line or an ignore line in the options file, the following type of errors can be ignored:

  • brokenold (hopefully never seen) โ€” if there are errors parsing an installed version of a package, donโ€™t error out; just assume itโ€™s older than literally anything else, has no files, or has no source name.
  • brokensignatures โ€” if a .changes or .dsc file contains at least one invalid signature and no valid signature (not even expired, or from an expired or revoked key), reprepro assumes the file got corrupted and refuses to use it unless this ignore directive is given.
  • brokenversioncmp (hopefully never seen) โ€” if comparing old and new version fails, assume the new one is newer.
  • dscinbinnmu โ€” if a .changes file has an explicit Source version that is different from the version header of the file, reprepro assumes itโ€™s a binary non-maintainer upload (NMU). In that case, source files are not permitted in .changes files processed by include or processincoming. Adding --ignore=dscinbinnmu allows it for the include command.
  • emptyfilenamepart (insecure) โ€” allow strings to be empty when theyโ€™re used to construct filenames (like versions, architectures, ...).
  • extension โ€” allow includedeb files that do not end with .deb, includedsc files not ending in .dsc, and include files not ending in .changes.
  • forbiddenchar (insecure) โ€” do not insist on Debian policy for package and source names and versions. Thus allowing all 7-bit characters but slashes (as they would break the file storage) and things syntactically active (spaces, underscores in filenames in .changes files, opening parentheses in source names of binary packages). To allow some 8-bit chars additionally, use 8bit additionally.
  • 8bit (more insecure) โ€” allow 8-bit characters not looking like overlong UTF-8 sequences in filenames and things used as parts of filenames. Though it hopefully rejects overlong UTF-8 sequences, there might be other characters your filesystem confuses with special characters, thus creating filenames possibly equivalent to /mirror/pool/main/../../../etc/shadow (which should be safe, as you do not run reprepro as root, do you?) or simply overwriting your conf/distributions file adding some commands in there. So do not use this if you are paranoid, unless you are paranoid enough to have checked the code of your libs, kernel and filesystems.
  • ignore (for forward compatibility) โ€” ignore unknown ignore types given to --ignore.
  • flatandnonflat (only suppresses a warning) โ€” do not warn about a flat and a non-flat distribution from the same source with the same name when updating. (Hopefully never ever needed.)
  • malformedchunk (I hope you know what you do) โ€” do not stop when finding a line not starting with a space but no colon (:) in it. These are otherwise rejected as they have no defined meaning.
  • missingfield (safe to ignore) โ€” ignore missing fields in a .changes file that are only checked but not processed. Those include: Format, Date, Urgency, Maintainer, Description, Changes.
  • missingfile (might be insecure) โ€” when including a .dsc file from a .changes file, try to get files needed but not listed in the .changes file (e.g. when someone forgot to specify -sa to dpkg-buildpackage) from the directory the .changes file is in instead of erroring out. (--delete will not work with those files, though.)
  • spaceonlyline (I hope you know what you do) โ€” allow lines containing only (but non-zero) spaces. As these do not separate chunks and thus will cause reprepro to behave unexpectedly, they cause error messages by default.
  • surprisingarch โ€” do not reject a .changes file containing files for an architecture not listed in the Architecture header within it.
  • surprisingbinary โ€” do not reject a .changes file containing .deb files containing packages whose name is not listed in the Binary: header of that changes file.
  • undefinedtarget (hope you are not using the wrong db directory) โ€” do not stop when the packages.db file contains databases for codename/packagetype/component/architectures combinations that are not listed in your distributions file.

This allows you to temporarily remove some distribution from the config files, without having to remove the packages in it with the clearvanished command. You might even temporarily remove single architectures or components, though that might cause inconsistencies in some situations.

  • undefinedtracking (hope you are not using the wrong db directory) โ€” do not stop when the tracking file contains databases for distributions that are not listed in your distributions file.

This allows you to temporarily remove some distribution from the config files, without having to remove the packages in it with the clearvanished command. You might even temporarily disable tracking in some distribution, but that is likely to cause inconsistencies in there, if you do not know what you are doing.

  • unknownfield (for forward compatibility) โ€” ignore unknown fields in the config files, instead of refusing to run then.
  • unusedarch (safe to ignore) โ€” no longer reject a .changes file containing no files for any of the architectures listed in the Architecture header within it.
  • unusedoption โ€” do not complain about command line options not used by the specified action (like --architecture).
  • uploaders โ€” the include command will accept packages that would otherwise have been rejected by the uploaders file.
  • wrongarchitecture (safe to ignore) โ€” do not warn about wrong Architecture: lines in downloaded Packages files. (Note that wrong Architectures are always ignored when getting stuff from flat repositories or importing stuff from one architecture to another.)
  • wrongdistribution (safe to ignore) โ€” do not error out if a .changes file is to be placed in a distribution not listed in that fileโ€™s Distribution: field.
  • wrongsourceversion โ€” do not reject a .changes file containing .deb files with a different opinion on what the version of the source package is. (Note: reprepro only compares literally here, not by meaning.)
  • wrongversion โ€” do not reject a .changes file containing .dsc files with a different version. (Note: reprepro only compares literally here, not by meaning.)
  • expiredkey (I hope you know what you do) โ€” accept signatures with expired keys. (Only if the expired key is explicitly requested.)
  • expiredsignature (I hope you know what you do) โ€” accept expired signatures with expired keys. (Only if the key is explicitly requested.)
  • revokedkey (I hope you know what you do) โ€” accept signatures with revoked keys. (Only if the revoked key is explicitly requested.)

๐Ÿงš GUESSING ๐Ÿงš

okay so when youโ€™re including a binary or source package and you didnโ€™t explicitly declare a component with -C, it will take the first component that matches: the name of the section, being a prefix to the section, being a suffix to the section, or having the section as a prefix or any. (In this order.)

Thus having specified the components: main non-free contrib non-US/main non-US/non-free non-US/contrib should map e.g. non-US to non-US/main and contrib/editors to contrib, while having only main non-free and contrib as components should map non-US/contrib to contrib and non-US to main.

NOTE: always specify main as the first component, if you want things to end up there.
NOTE: unlike in dak, non-US and non-us are different things...

๐ŸŒธ NOMENCLATURE ๐ŸŒธ

  • Codename โ€” the primary identifier of a given distribution. These are normally things like sarge, etch or sid.
  • basename โ€” the name of a file without any directory information.
  • byhand โ€” changes files can have files with section byhand (Debian) or raw- (Ubuntu). Those files are not packages but other data generated (usually together with packages) and then uploaded together with this changes file.

With reprepro those can be stored in the pool next to their packages with tracking, put in some log directory when using processincoming, or given to a hook script (currently only possible with processincoming).

  • filekey โ€” the position relative to the outdir. (As found in Filename: in Packages.gz.)
  • full filename โ€” the position relative to /.
  • architecture โ€” the term like sparc, i386, mips, ... . To refer to the source packages, source is sometimes also treated as architecture.
  • component โ€” things like main, non-free and contrib (by policy and some other programs also called section, reprepro follows the naming scheme of apt here.)
  • section โ€” things like base, interpreters, oldlibs and non-free/math (by policy and some other programs also called subsections).
  • md5sum โ€” the checksum of a file in the format "<md5sum of file> <length of file>".

๐ŸŒธ Some note on updates ๐ŸŒธ

๐Ÿ’… A version is not overwritten with the same version

bestie. reprepro will never update a package with a version it already has. No cap. That would be like rebuilding the whole entire database with every single upgrade, and we are simply not doing that.

To force the new same version in, remove it and then update. Easy.

Okay but listen โ€” if files of the packages changed without changing their name, make sure the file is no longer remembered by reprepro. Without --keepunreferencedfiled and without errors while deleting, it should already be forgotten. Otherwise a deleteunreferenced or even some __forget might help. ๐Ÿซถ

โœจ The magic delete rule (-)

A minus as a single word in the Update: line of a distribution marks everything to be deleted. Iconic, honestly. ๐Ÿ’€

The mark causes later rules to get packages even if they have (strict) lower versions. The mark will get removed if a later rule sets the package on hold (hold is not yet implemented, in case you might wonder) or would get a package with the same version (which it will not, see above). If the mark is still there at the end of the processing, the package will get removed.

So:

  • the line Update: - rules will cause all packages to be exactly the highest Version found in rules.
  • the line Update: near - rules will do the same, except if it needs to download packages, it might download it from near except when too confused.

It will get too confused, for example, when near or rules have multiple versions of the package and the highest in near is not the first one in rules, as it never remember more than one possible spring for a package. ๐Ÿ˜ญ

โš ๏ธ Warning: this rule applies to all type/component/architecture triplets of a distribution, not only those some other update rule applies to. That means it will delete everything in those. Please do not do a little oopsie here. ๐Ÿ™ˆ

๐Ÿ’– ENVIRONMENT VARIABLES ๐Ÿ’–

Environment variables are always overwritten by command line options, but they overwrite options set in the options file. Yes, even when the options file is obviously parsed after the environment variables, as the environment may determine the place of the options file. The lore is real. ๐ŸŒ€

  • REPREPRO_BASE_DIR โ€” the directory in this variable is used instead of the current directory, if no -b or --basedir options are supplied. It is also set in all hook scripts called by reprepro (relative to the current directory or absolute, depending on how reprepro got it).
  • REPREPRO_CONFIG_DIR โ€” the directory in this variable is used when no --confdir is supplied. It is also set in all hook scripts called by reprepro (relative to the current directory or absolute, depending on how reprepro got it).
  • REPREPRO_OUT_DIR โ€” this is not used, but only set in hook scripts called by reprepro to the directory in which the pool subdirectory resides (relative to the current directory or absolute, depending on how reprepro got it).
  • REPREPRO_DIST_DIR โ€” this is not used, but only set in hook scripts called by reprepro to the dists directory (relative to the current directory or absolute, depending on how reprepro got it).
  • REPREPRO_LOG_DIR โ€” this is not used, but only set in hook scripts called by reprepro to the value setable by --logdir.
  • REPREPRO_CAUSING_COMMAND / REPREPRO_CAUSING_FILE โ€” those two environment variables are set (or unset) in Log: and ByHandHooks: scripts and hint what command and what file caused the hook to be called (if there is some).
  • REPREPRO_CAUSING_RULE โ€” this environment variable is set (or unset) in Log: scripts and hints what update or pull rule caused this change.
  • REPREPRO_FROM โ€” this environment variable is set (or unset) in Log: scripts and denotes what other distribution a package is copied from (with pull and copy commands).
  • REPREPRO_FILTER_ARCHITECTURE
  • REPREPRO_FILTER_CODENAME
  • REPREPRO_FILTER_COMPONENT
  • REPREPRO_FILTER_PACKAGETYPE
  • REPREPRO_FILTER_PATTERN โ€” set in FilterList: and FilterSrcList: scripts.
  • GNUPGHOME โ€” not used by reprepro directly. But reprepro uses libgpgme, which calls gpg for signing and verification of signatures. And your gpg will most likely use the content of this variable instead of ~/.gnupg. Take a look at gpg(1) to be sure. You can also tell reprepro to set this with the --gnupghome option.
  • GPG_TTY โ€” when there is a gpg-agent running that does not have the passphrase cached yet, gpg will most likely try to start some pinentry program to get it. If that is pinentry-curses, that is likely to fail without this variable, because it cannot find a terminal to ask on. In these cases you might set this variable to something like the value of $(tty) or $SSH_TTY or anything else denoting a usable terminal. (You might also want to make sure you actually have a terminal available. With ssh you might need the -t option to get a terminal even when telling gpg to start a specific command.)

By default, reprepro will set this variable to what the symbolic link /proc/self/fd/0 points to, if stdin is a terminal, unless you told with --noguessgpgtty to not do so. ๐Ÿงš


๐Ÿ’€ BUGS ๐Ÿ’€

Increased verbosity always shows those things one does not want to know. (Though this might be inevitable and a corollary to Murphy.) ๐Ÿ˜ญ

reprepro uses berkeley db, which was a big mistake. The most annoying problem not yet worked around is database corruption when the disk runs out of space. (Luckily if it happens while downloading packages while updating, only the files database is affected, which is easy โ€” though time consuming โ€” to rebuild, see recovery file in the documentation.) Ideally put the database on another partition to avoid that. Please. For me. ๐Ÿฅบ

While the source part is mostly considered as the architecture source, some parts may still not use this notation.


๐ŸŒˆ WORK-AROUNDS TO COMMON PROBLEMS ๐ŸŒˆ

gpgme returned an impossible condition

With the woody version this normally meant that there was no .gnupg directory in $HOME, but it created one and reprepro succeeds when called again with the same command. Since sarge the problem sometimes shows up, too. But it is no longer reproducible and it does not fix itself, neither. ๐Ÿ˜ตโ€๐Ÿ’ซ

Try running gpg --verify file-you-had-problems-with manually as the user reprepro is running and with the same $HOME. This alone might fix the problem. It should not print any messages except perhaps:

gpg: no valid OpenPGP data found.
gpg: the signature could not be verified.

if it was an unsigned file.

not including .orig.tar.gz when a .changes file's version does not end in -0 or -1

If dpkg-buildpackage is run without the -sa option to build a version with a Debian revision not being -0 or -1, it does not list the .orig.tar.gz file in the .changes file. If you want to include such a file with reprepro when the .orig.tar.gz file does not already exist in the pool, reprepro will report an error. ๐Ÿซ 

This can be worked around by:

  • call dpkg-buildpackage with -sa (recommended)
  • copy the .orig.tar.gz file to the proper place in the pool before
  • call reprepro with --ignore=missingfile (discouraged)

leftover files in the pool directory.

reprepro is sometimes a bit too timid of deleting stuff. When things go wrong and there have been errors it sometimes just leaves everything where it is. To see what files reprepro remembers to be in your pool directory but does not know anything needing them right now, you can use:

reprepro dumpunreferenced

To delete them:

reprepro deleteunreferenced

๐ŸŽ€ INTERRUPTING ๐ŸŽ€

Interrupting reprepro has its problems. Some things (like speaking with apt methods, database stuff) can cause problems when interrupted at the wrong time. Then there are design problems of the code making it hard to distinguish if the current state is dangerous or non-dangerous to interrupt. ๐Ÿ˜ฌ

Thus if reprepro receives a signal normally sent to tell a process to terminate itself softly, it continues its operation, but does not start any new operations. (I.e. it will not tell the apt-methods any new file to download, it will not replace a package in a target, unless it already had started with it, it will not delete any files gotten dereferenced, and so on.)

It only catches the first signal of each type. The second signal of a given type will terminate reprepro. You will risk database corruption and have to remove the lockfile manually. ๐Ÿ’€

Also note that even normal interruption leads to code-paths mostly untested and thus expose a multitude of bugs including those leading to data corruption. Better think a second more before issuing a command than risking the need for interruption. Fr fr. ๐Ÿซถ


๐Ÿฆ‹ REPORTING BUGS ๐Ÿฆ‹

Report bugs or wishlist requests to the Debian BTS (e.g. by using reportbug reprepro under Debian) or directly to brlink@debian.org


Copyright ยฉ 2004,2005,2006,2007,2008,2009,2010,2011,2012 Bernhard R. Link (http://www.brlink.eu)

This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


okay bestie thatโ€™s the whole page, and the little footer energy is: this is reprepro, dated 2013-05-04, and the manual section is REPREPRO(1) โ€” periodt ๐Ÿ’…โœจ

๐Ÿ“ฆ where this page comes from