Package: reprepro
Severity: normal
Apologies if I seem to not have understand correctly how apt and repositories
and stuff are organized, I'm not that much into it.
I think the workaround addressing the problem with the debian security archive
described at the "FakeComponentPrefix" section in the reprepro manpage could
be done better.
When I try to mirror the Debian Security Archive, I might create
conf/{distributions,updates} files like this:
Codename: lenny/updates
FakeComponentPrefix: updates
Architectures: i386
Components: main
Update: security-updates
Name: security-updates
Method: http://security.debian.org/
The FakeComponentPrefix line is used here to get a Release file that holds
lenny instead of lenny/updates in the Codename line, and updates/main instead
of main in the Components line. This is the way it is at the Debian security
mirror, and it's thusly just the way apt expects it when I try to install from
the locally generated reprepro repository.
Leaving out the FakeComponentPrefix line and setting directly Codename: lenny
and Components: updates/main would result in apt not finding the Release file,
as it is called to look for it under the Codename: value although it being
under dists/lenny/updates.
Am I right so far? Now I'm asking why the above configuration produces a file
structure like pool/main. Couldn't it produce a file structure like
pool/updates/main, just the way it is at the Debian Security Archive? This way
we would be able to get the non-security and security parts of a distribution
in one reprepro archive, because the package files wouldn't overlap (
overlapping leads to checksum error and reprepro aborting).
As reprepro terminology "FakeComponentPrefix" wouldn't fit the behaviour
exactly anymore and would also render users' old configs invalid/not working
anymore, I would propose to deprecate FakeComponentPrefix and use a new
Identifier, as here in example conf/distributions:
Codename: lenny
AptPostfix: updates
Architectures: i386
Components: updates/main
Update: security-updates
as this also reflects better what we want, I mean isn't it just the "lenny"
distribution? Calling it lenny/update would only blur the fact that the two
indeed belong together.
The "AptPostfix: updates" line here would make apt search the Release file at
dists/lenny/updates/Release where it indeed is (I guess that's because so it
doesn't overlap with dists/lenny/Release wich is the Release file of the
non-security part).
As I said, if my point of view does not go hand in hand with how apt and
repositories are meant to be, I apologize. Apologies also for this "long story,
short meaning" bugreport.
Regards,
Jens Stimpfle
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages reprepro depends on:
ii libarchive1 2.4.17-2 Single library to read/write tar,
ii libbz2-1.0 1.0.5-1 high-quality block-sorting file co
ii libc6 2.7-18lenny2 GNU C Library: Shared libraries
ii libdb4.6 4.6.21-11 Berkeley v4.6 Database Libraries [
ii libgpg-error0 1.4-2 library for common error values an
ii libgpgme11 1.1.6-2 GPGME - GnuPG Made Easy
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
Versions of packages reprepro recommends:
ii apt 0.7.20.2+lenny1 Advanced front-end for dpkg
Versions of packages reprepro suggests:
ii gnupg-agent 2.0.9-3.1 GNU privacy guard - password agent
pn inoticoming <none> (no description available)
ii lzma 4.43-14 Compression method of 7z format in
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
