Re: Error upgrading to woody: mv: cannot create file `/etc/exim/exim.conf'
(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 <mbaker@iee.org>
+ 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 <branden@debian.org>
+ 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 [cjwatson@flatline.org.uk]
Reply to: