This is a list of "frequently" asked questions. 1.1) What can I do when reprepro complains about a missing .orig.tar.gz? 1.2) Why does it refuse a file when one in another suite has the same name? 1.4) The key to sign my Release files needs a passphrase, what to do? 1.5) How do I change how files are downloaded. 1.6) How to omit packages missing files when updating. 2.1) Does reprepro support to generate Release.gpg files? 2.2) Does reprepro support tildes ('~') in versions? 2.3) Does reprepro support generation of Contents-.gz files? 3.1) Can I have two versions of a package in the same distribution? 3.2) Can reprepro pass through a server-supplied Release.gpg? 9) Feature ... is missing, can you add it? 1.1) What can I do when reprepro complains about a missing .orig.tar.gz? ------------------------------------------------------------------------ When 'include'ing a .changes file reprepro by default only adds files referenced in the .changes file into the pool/-hierarchy and does not search for files referenced in a .dsc file and thus fails if this .orig.tar.gz is not already in the pool. You are facing the choice: - copy the .orig.tar.gz by hand into the appropriate place within pool/ and try again. reprepro will find it there when you try it the next time and add it to its database. - use --ignore=missingfile to tell reprepro to search for such files in the directory the .changes file resides in. - modify the .changes file by hand to reference the .orig.tar.gz - use changestool (comes with reprepro since version 1.3.0) to list the file. ("changestool <.changesfile> includeallsources") - use dpkg-buildpackage -sa the next time you build a package so that it calls dpkg-genchanges with -sa which then always lists .orig.tar.gz and not only if it ends in -0 or -1. 1.2) Why does it refuse a file when one in another suite has the same name? ---------------------------------------------------------------------------- Reprepro uses Debian's way to organize the pool hierarchy, which means that the directory and name a file is saved under is only determined by its sourcename, its name and its version and especially not by the distribution it belongs to. (This is the intent of having a pool directory, so that if two distributions have the same version, the disk space is only used once). This means that if different versions of a packaged having the same version string are put in the same reprepro repository (even if put into different distributions within that), reprepro will refuse to do so. (Unless you have a md5sum collision, in which case it will put the one and just replace the second with the first). The only way to work around, is too put the different distributions into different repositories. But in general it is really worth the effort to get the versioning right instead: Having multiple packages with the same version make it hard to track down problems, because it is easy to mix them up. Also up/downgrading a host from one distribution to the other will not change the package but just keep the old (as they are the same version, so they have to be the same, apt and dpkg will think). How to deal with this without separating repositories depends on how you reached this situation: - in the past Debian's stable and stable-security buildds sometimes both built a package and for some architectures the one version entered security.debian.org and the other ftp.debian.org with the next point release. (This should be fixed now. And it is always considered a bug, so if you hit this, please report it). If you mirror such a situation, just update one of the distributions and manually include the package into the other distribution. As the versions are the same, reprepro will keep with this and not try to download the other version, err other same version, err ... - backports (i.e. packages rebuild for older distributions) Common practise is to append the version with reducing ~, i.e. 1.0-1 becomes 1.0-1~bpo.7, or 3.0 becomes 3.0~sarge. (This makes sure that if a host is updated the backport is replaced by the real package). If backporting to multiple distributions you get bonus points for making sure newer distributions have higher version numbers. (To make sure which version is considered newer by dpkg use dpkg's --compare-versions action). - a package built for multiple distributions is equivalent to the backports case - locally modified packages that should be replace by newer official versions: append something like "a0myname". If it should be replaced by security updates of the official package, make sure (using dpkg's --compare-versions) that a security update would have a higher version. - locally modified packages that should not be replaced by newer official versions: prefix the version with "99:" and perhaps appending it with something like "-myname". (appending only makes it easier to distinguish, as some tools do not show epochs). 1.4) The key to sign my Release files needs a passphrase, what to do? --------------------------------------------------------------------- Please take a look at gpg-agent. You can also use the --ask-passphrase option, but please note this is quite insecure. 1.5) How do I change how files are downloaded. ---------------------------------------------- reprepro just calls apt's methods for file retrieval. You can give them options in conf/updates like Config: Acquire::Http::Proxy=http://proxy.yours.org:8080 or replace them with other programs speaking the same interface. 1.6) How to omit packages missing files when updating. ------------------------------------------------------ reprepro does not like broken upstream repositories and just splits out errors and does not process the rest. (Implementing simply a ignore for that is not that easy, as I would have special case holding an old version in that case when unavailable packages should be deleted, and make some costly information-pushing between layers (after all, each file can belong to multiple packages and packages can have more than one file, so keeping track which package should get a mark that files where missing needs a n-to-n relation that should never be uses expect the case where such a error happens)). What you can do when a upstream repository you update from misses a file: - try once with a different mirror not missing those files. You can either change the mirror to use once and change it back afterwards. Or if both mirrors have the same inner directory structure (they usually have) and are accessible via the same method (like both http or both ftp) you can also use the Fallback: option in conf/updates to tell reprepro to get missing files from the other Mirror. This an even be used for things not being a mirror of the same thing, but only having some files at the same place. For example to work around etch r1 listing many older kernel packages but no longer having the needed files, a line Fallback: http://snapshot.debian.net/archive/2007/04/02/debian/ can help. (But make sure to look at the run and remove this line once reprepro downloaded the missing files. With this line active and the primary mirror you list in Method: unreachable, reprepro will also download index files from snapshot and make your repository a copy of unstable from 2007-04-02 instead of an updated etch version.) - get the file elsewhere (with the correct md5sum), place it in the appropriate place in the pool/ hierarchy and do the update. Reprepro will see the file is already there, add it to its database and just continue with the update. - tell reprepro to exclude this package * There are multiple ways to do so. Easiest is adding something like FilterFormula: package (!= xen-shell) or FilterFormula: package (!= xen-shell) | version (!=1.0-2) | !files to your rule in conf/updates. ( the "| ! files" tells it to only omit the source package xen-shell, as source packages have a files field. Make sure the package in question does not require you to make the source available or you are not making your repository accessible to others). * Another way is adding something like FilterList: install excludefile and adding a file conf/excludefile with content xen-shell deinstall (the install will tell it to install what is not listed in the file, the deinstall on xen-shell will tell it to not install that package) * Finally you can also supply a ListHook: with a script copying its first argument to the second argument, removing all occurrences of the package you do not want (take a look intro the dctrl-tool package for tools helping you with this). - the worst solution is to just propagate the problem further, by just telling reprepro the file is there with the correct md5sum while it is not. (Via the _addmd5sums command of reprepro). Unless you run checkpool reprepro will not notice what you have done and will not even try to download that file once it becomes available. So don't do this. 2.1) Does reprepro support to generate Release.gpg files? --------------------------------------------------------- Yes, add a SignWith in the suite's definition in conf/distributions. (and take a look what the man page says about SignWith) 2.2) Does reprepro support tildes ('~') in versions? ---------------------------------------------------- Yes, but in .changes files only since version 0.5. (You can work around this in older versions by using includedeb and includedsc on the .deb and .dsc files within the .changes file, though) 2.3) Does reprepro support generation of Contents-.gz files? ------------------------------------------------------------------ Yes, since version 1.1.0 (well, actually since 0.8.2 but a bug caused the generated files to not be up to date unless manually exporting the distributions in question). Look for "Contents" in the man page. 3.1) Can I have two versions of a package in the same distribution? ------------------------------------------------------------------- Sorry, this is not possible right now, as reprepro heavily optimizes at only having one version of a package in a suite-type-component-architecture quadruple. You can have different versions in different architectures and/or components within the same suite. (Even different versions of a architecture all package in different architectures of the same suite). But within the same architecture and the same component of a distribution it is not possible. 3.2) Can reprepro pass through a server-supplied Release.gpg? ------------------------------------------------------------------- No. The reason for this is that the Release file will be different, so a Release.gpg would not match. The reason that the Release file looks differently is that reprepro mirrors packages. While it can create a distribution with the same packages as a distribution it mirrors. It will decide on its own where to put the files, so their Filename: or Directory: might differ. It may create a different set of compressions for the generated index files. It does not mirror Packages.diff directories (but only comes with helpers to create diffs between different states of the mirror). It does not mirror Contents files but creates them; and so on. So to be able to mirror distribution signatures almost all the functionality of reprepro would need to be duplicated (once supporting literal mirroring, once support local packages, partial mirroring, merging mirroring, pool condensing), thus I decided that this is better a task for another program. (Note that if you already have a local literal mirror, you can also use that as upstream for partial/merged/extended mirrored distributions of that. If you use the file:/// in Method: (as opposed to copy:///), reprepro will make hardlinks for files in pool/ if possible). 9) Feature ... is missing, can you add it? ------------------------------------------ First, please take another look at the man page. My documentation is not very good, so it is easy to overlook some feature even when it is described already. If it is not there, just write me a mail (or better write a wishlist report to the Debian BTS, then it cannot get lost). Some things I add quite fast, other stuff takes a bit. Things incompatible with the current underlying infrastructures or past design decisions may never come, but if I have it on the TODO list of things to add, it help the code to develop in a direction that things like that might be possible in the future.