path: root/docs/FAQ

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