Re: May I temporarily move away a conffile of a conflicting package?
On Fri, Mar 21, 2003 at 04:52:09PM +0100, Andreas Metzler wrote:
> For a complete discusssion see http://bugs.debian.org/183357
>
> Currently the exim4-packages cannot provide /usr/sbin/exim (only
> /usr/sbin/exim4) because exim v3's init script up to version 3.36-4 uses
> something aequivalent to this to check whether it should do anything: [ -x
> /usr/sbin/exim ] || exit. If you had exim v3 uninstalled (but not purged)
> and installed exim v4 and it contained /usr/sbin/exim both init-scripts
> would try to run a daemon. THe ame applies to the cron-snippets.
We ran into the same problem with dhcp/dhcp3-server, though thankfully few
users are likely to be in the habit of running dhcpd by hand, so we just
renamed the daemon binary.
I think there should be some discussion on -devel about a better way to do
this test.
Will th e exim3 init script actually fail to start exim4 correctly? Or does
it work?
> The exim3 init script in sid has already been changed to use another test
> that recognizes exim v3 properly but this doesn't help the users who will
> upgrade from woody to sarge (when it is stable), switching directly to
> exim v4 without installing eximv3 from sarge first.
It also does not help users who have removed (but not purged) exim in order
to upgrade to exim4.
>This
> leaves me with these possibilties:
> * don't ship /usr/sbin/exim in sarge, wait for sarge+1. I'd rather not
> do that because it'll take imho at least another two and a half
> years.
> * do something unclean. See below.
>
> Idea:
> * postinst configure
> 1 When eximv4 is installed check whether eximv3 conffiles using the
> bad test are installed, otherwise goto end
> 2 move the respective file to $file.exim4disabled and generate a new
> $file that says "This file has been temporarily renamed, see
> $file.exim4disabled."
> * postrm uninstall:
> if [ -e $file.exim4disabled ] && md5sum shows it is not changed
> if [ -e $file ]
> # exim v3 has still not been purged
> mv $file.exim4disabled $file
> else # exim v3 has been purged
> rm $file.exim4disabled
> fi
> else do nothing.
>
> Is this allowed? Yes[ ] No[ ]
> Is this too fragile Yes[ ] No[ ]
Ordinarily, a diversion would be a less fragile way to accomplish the same
thing, but diversions are advertised as being inadvisable when dealing with
conffiles.
There is some question in my mind as to whether this is allowed by policy,
and a greater question as to whether this follows the spirit of preserving
the user's configuration.
If the automated methods are not feasible, you can always fall back on
alerting the user of the situation.
I would suggest bringing this up on debian-devel to get more input.
--
- mdz
Reply to: