1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
|
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 an other 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?
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 an other 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 intend 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.
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.
|
