Here is a scenario in which I could reproduce this bug. In a Lenny
chroot, I installed mksh and ran "dpkg-reconfigure mksh" to let it point
at /bin/sh. Upgrading to Squeeze, I confirmed the question to let dash
provide /bin/sh. This brought up another debconf screen:
┌─────────────────────────────────────┤ Configuring mksh
├──────────────────────────────────────┐
│
│
│ Cannot install mksh as /bin/sh!
│
│
│
│ Because dash has already been configured to be installed as /bin/sh, mksh
cannot be │
│ installed as /bin/sh. Use "dpkg-reconfigure dash" to change dash to not
install as /bin/sh, │
│ then "dpkg-reconfigure mksh" to install mksh there.
│
│
│
│ <Ok>
│
│
│
└───────────────────────────────────────────────────────────────────────────────────────────────┘
Unpacking dash failed then:
,----
| Unpacking dash (from .../dash_0.5.5.1-2.3_i386.deb) ...
| dpkg: error processing /var/cache/apt/archives/dash_0.5.5.1-2.3_i386.deb
(--unpack)
| trying to overwrite `/usr/share/man/man1/sh.1.gz', which is also in package
bash
`----
And /bin/sh still pointed at mksh. The only way to resolve this was to
"dpkg-reconfigure mksh" again to let it _not_ provide /bin/sh, after
which the upgrade succeeded.
I haven't analyzed this in detail, but I suppose this situation will
occur whenever /bin/sh is diverted and points to something else than
dash.
Sven
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
