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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
