Your message dated Mon, 3 May 2010 13:35:52 +0200
with message-id <20100503113552.ga1...@pcpool00.mathematik.uni-freiburg.de>
and subject line Re: Bug#580040: Requesting a limit of how much change an
update can do
has caused the Debian Bug report #580040,
regarding Requesting a limit of how much change an update can do
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
580040: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580040
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: reprepro
Version: 4.0.2-1
Severity: normal
Hi,
I recently updated a verry old reprepro instance and it changed the
interface for filter scripts. Before the update it would give the
Packages.gz file as first argument while not it gives the uncompressed
Packages. The filter script used 'zcat "$1" | ...; exit 0'. Since zcat
does not cope with uncompressed files the filter script produced a
completly empty package list. Subsequently all of the mirror was
removed.
Now this isn't reprepros fault but it would be nice if reprepro would
protect aginst this. This could also happen if upstreams Packages file
gets created empty for some reason. It would be nice if reprepro would
have a limit of how much change a single update may produce. Say no
more than +/-10% of the old archive. If more is changed a command line
option should be needed to override this. The 10% should be
configurable obviously.
MfG
Goswin
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.31.5-book-1 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages reprepro depends on:
ii libarchive1 2.6.2-1 Single library to read/write tar,
ii libbz2-1.0 1.0.5-4 high-quality block-sorting file co
ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib
ii libdb4.8 4.8.26-1 Berkeley v4.8 Database Libraries [
ii libgpg-error0 1.6-1 library for common error values an
ii libgpgme11 1.2.0-1.2 GPGME - GnuPG Made Easy
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
Versions of packages reprepro recommends:
ii apt 0.7.25.1 Advanced front-end for dpkg
Versions of packages reprepro suggests:
ii gnupg-agent 2.0.14-1 GNU privacy guard - password agent
pn inoticoming <none> (no description available)
ii lzma 4.43-14 Compression method of 7z format in
ii xz-utils 4.999.9beta+20100117-1 XZ-format compression utilities
-- no debconf information
--- End Message ---
--- Begin Message ---
* Goswin von Brederlow <goswin-...@web.de> [100503 12:18]:
> I recently updated a verry old reprepro instance and it changed the
> interface for filter scripts. Before the update it would give the
> Packages.gz file as first argument while not it gives the uncompressed
> Packages. The filter script used 'zcat "$1" | ...; exit 0'. Since zcat
> does not cope with uncompressed files the filter script produced a
> completly empty package list. Subsequently all of the mirror was
> removed.
>
> Now this isn't reprepros fault but it would be nice if reprepro would
> protect aginst this. This could also happen if upstreams Packages file
> gets created empty for some reason. It would be nice if reprepro would
> have a limit of how much change a single update may produce. Say no
> more than +/-10% of the old archive. If more is changed a command line
> option should be needed to override this. The 10% should be
> configurable obviously.
That would cause an incompatible change for all the cases where one
only want to get a small number of packages from that.
The change for the ListHook is also quite an old one, so I see no reason
to introduce an incompatible change for that.
Reprepro should abort if the script returns an error. So I guess an
set -e earlier should have made catching this easy.
Thus I'm closing this bug...
--- End Message ---
