[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#463260: apt-utils: apt-ftparchive caches hashes too aggressively?



Any software engineer will willfully tell you that software development involves planned chaos. It is obvious to this computer scientist that you have enough experience with networking and system management to know that 'keep it simple' is the order of the day. The easy way is scientific enough. I suggest the easy solution to be the investigation, acquisition and installation of software from the subversion project. It is a replacement for CVS, which supersedes RCS and complements the apt suite.
 
Think of it as one more tool in the toolkit.
 
On 1/30/08, John Morrissey <jwm@horde.net> wrote:
Package: apt-utils
Version: 0.6.46.4-0.1
Severity: normal

A little background (thought this might be useful to understand our use
cases):

We preseed d-i to build new machines, and have local packages that can turn
this base installation into nearly every type of machine we manage (e-mail,
web servers, application servers, etc.) simply by installing the appropriate
.deb from our local APT repository. These packages Depends: on the
appropriate packages, and have file contents and maintainer scripts that set
the machine up automatically.

These packages are built with dpkg-deb(1), since there isn't really any
"source" to build a binary package from. Instead, we have a hier (with a
DEBIAN directory) for each package that we drop files and maintainer scripts
into. We then have a wrapper around dpkg-deb(1) that builds the .deb and
inserts it into our local repo, then runs apt-ftparchive to update the repo
metadata. We have apt-ftparchive use its cache, since it obviously makes a
significant reduction in how long it takes to update the metadata.


It seems apt-ftparchive might be too aggressive with its caching. When a .deb
changes, apt-ftparchive doesn't notice and continues to use metadata (file
size, MD5sum, etc.) from the cache. When attempting to install a package
affected by this, apt-get(1) yields:

Failed to fetch http://example.com/debian/dists/isis/main/binary-i386/isis-mx-server_1.8-1_all.deb  Size mismatch
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

Generally, a package shouldn't change once built with a given version, but
people occasionally forget to bump a package's version before building,
which creates a lot of confusion until they realize what happened, and the
reason for it. Sometimes people mistakenly rebuild a package, too, and a
simple rebuild (with no content change) causes the .deb's MD5sum to change.

Occasionally, it's also useful for us to make changes to the existing
version of a package so we can avoid an unnecessary package update on
machines with it installed. For example, if we make an emergency
configuration change on the machines themselves, it's useful to modify the
package hier and rebuild with the same version number, saving a package
update on the machines that would have no net effect. I realize this isn't
(AFAIK) a typical use case in Debian proper.

Lastly, the version of apt-ftparchive in sarge did not exhibit this
aggressive caching; if a .deb in the repo changed, the cache metadata was
updated. I'm not sure what apt-ftparchive checked; maybe file mtime on the
.deb?

Is there a way to avoid/change this aggressive caching without having to
stop using the cache? Our repo isn't huge by Debian standards, but it still
takes a couple minutes to rebuild without the cache, and we'd like to avoid
going cacheless or having to periodically remove the cache when we encounter
this behavior.

-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: alpha
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-alpha-smp
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages apt-utils depends on:
ii  apt [libapt-pkg-libc6. 0.6.46.4-0.1      Advanced front-end for dpkg
ii  libc6.1                2.3.6.ds1-13etch4 GNU C Library: Shared libraries
ii  libdb4.4               4.4.20-8          Berkeley v4.4 Database Libraries [
ii  libgcc1                1:4.1.1-21        GCC support library
ii  libstdc++6             4.1.1-21          The GNU Standard C++ Library v3

apt-utils recommends no packages.

-- no debconf information



--
To UNSUBSCRIBE, email to deity-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: