(Mail-Followup-To: set to -user only. I'd also appreciate not being directly cc'ed on your questions; I read both -user and -devel, so I got three copies of this!)
On Mon, Sep 03, 2001 at 11:01:56PM -0700, tluxt wrote: > In fact, the directory: > /etc/exim > does not exist. You can create it yourself, as a workaround for now. > In my /v/c/a/a I have: > @debian:/var/cache/apt/archives$ ls -al exim* > -rwxr-xr-x 1 root root 650710 Jun 9 19:45 > exim_3.12-10.1_i386.deb > -rwxr-xr-x 1 root root 650572 May 2 2000 exim_3.12-10_i386.deb > -rwxr-xr-x 1 root root 746472 Apr 11 17:28 exim_3.22-4_i386.deb > -rwxr-xr-x 1 root root 747228 Jul 18 16:50 exim_3.31-1_i386.deb > -rwxr-xr-x 1 root root 748988 Aug 14 17:30 exim_3.32-2_i386.deb > @debian:/mnt/hda11/var/cache/apt/archives$ > > My Question: > I don't know enough about Debian to know if this is a bug - would you > please enlighten me? > The msg from CW said, on 8/14, that exim 3.32-1 fixes this. > I have exim 3.32-2 in my cache. You must have got that manually, or when apt was temporarily pointing at unstable. apt uses whatever's in its package list, not necessarily the contents of the cache. > Q: Since it is over 2 weeks past 8/14, shouldn't my dist-upgrade > be using 3.32, which, presumably, has this bug fixed? It's not that simple. Testing is not just "two weeks behind unstable"; the algorithm is a lot more complex than that, and is more like: * Look at the 'urgency' field of the new package. low => 10 days, medium => 5 days, high => 2 days, critical => 0 days. Wait that long before doing anything else. If a new version of the package is uploaded in the meantime, the count is reset. * Do all architectures in woody have the same version of the package compiled for them? If not, give up. * Does the version in sid have more release-critical bugs than the version in woody? If so, give up. * Experimentally upgrade the package in woody, together with all packages that come from the same source package. After doing this, does the number of packages that can't be installed at all in woody due to broken dependencies go down, or at least stay the same? If so, it's OK to upgrade the package. If not, the package has to wait. I'm sure you can see now that you can't just say "wait two weeks, then it should be in testing". For the status of any individual package (plus some explanation), you can look at http://ftp-master.debian.org/testing/. Some of it's a bit cryptic, and you have to do more digging to find out exactly what's going on sometimes, but it's there. In the case of exim, update_excuses.html says: * exim 3.32-2 (currently 3.31-1) (important) (low) + Maintainer: Mark Baker <[EMAIL PROTECTED]> + exim uploaded 19 days ago, out of date by 9 days! + valid candidate (will be installed unless it's dependent upon other buggy pkgs) OK, so the first three steps above are passed. For the last, look at update_output.txt, which says, down near the end: exim: alpha: eximon This means that exim can't be upgraded because the eximon package would be uninstallable on alpha if it did. Doing some more investigation, this is because eximon depends on XFree86 4.1.0 on alpha, which hasn't got into testing yet. However, it should be there in two days, if nothing goes wrong in the meantime: * xfree86 4.1.0-4 (currently 4.0.3-4) (optional) (medium) + Maintainer: Branden Robinson <[EMAIL PROTECTED]> + only 3/5 days old + not considered At that point, exim should be upgraded too, unless there are other problems. > Also, if this _is_ a bug that's not submitted yet, I don't know enough > yet about the bug tracking system, etc., to properly submit this. > So, I hope _you_, dear reader, will submit this bug to the system, > if it is indeed a current, non-submitted bug. It's not a bug there's any point reporting. All that the exim maintainer can do about it is refrain from uploading anything for two days; package maintainers don't get to influence what's in testing directly. Anybody else will tell you to wait for the testing bot to synchronize things. Tracking bugs in the various distributions of Debian (potato, woody, and sid) is an outstanding general problem. We have a crude system of tags which helps a little, but really the best we can do is try to ensure that the testing and unstable distributions are as close to each other as possible. Cheers, -- Colin Watson [EMAIL PROTECTED]