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