It it a package's job to deal with moving a conffile if the conffile is
renamed.
In the more general case though when a conffile is not renamed but is
removed from a package, I do not know whether the package or dpkg is at
fault if the old conffile is left behind on upgrade. Probably the
package, as dpkg cannot know if this conffile was really renamed or not.
----- Forwarded message from jeremy@jsbygott.fsnet.co.uk -----
From: jeremy@jsbygott.fsnet.co.uk
Date: Fri, 6 Sep 2002 17:11:08 +0100 (BST)
To: Joey Hess <joeyh@debian.org>
Subject: When conffiles get cut adrift
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
X-Spam-Status: No, hits=-2.9 required=5.0
tests=NO_REAL_NAME,AWL
version=2.31
Thanks for dealing so swiftly with the potato-WELCOME upgrade-bug.
More importantly, thanks for all your work on Debian generally.
Perhaps you could explain something to me? (I don't subscribe to
debian-devel or debian-policy, so I'm sorry if this was all discussed
_years_ ago!)
Best wishes,
Jeremy.
-----------------------------------------------------------------------------
Dr J S Bygott, Oxford. jeremy@jsbygott.fsnet.co.uk
-----------------------------------------------------------------------------
I assume it is a bug when a package creates a file on the system and
this file remains after the package is purged. (I don't mean cases
when some other package now controls the file.)
This seems to happen routinely when a package with a conffile is
upgraded to a new version which no longer has this conffile.
(Perhaps, this has changed in recent versions of dpkg? My potato ->
woody upgrade was done using potato dpkg. Unfortunately.)
I can't find explicit guidance for this situation in (version 3.5.6.1
of) the policy manual.
What can be done about it? To do nothing seems a bad idea. That just
imposes an additional burden on every systems administrator (including
people like me, who are not full-time sysadmins, but are trying to run
a reliable, clean system on which to do their real work).
Below is a fairly typical example. I have a number of questions: (1)
Would my suggested bugfix work? (2) Would it comply with policy? (3)
Should I report it as a bug? (4) Should I report similar bugs in
other packages?
Package: tetex-base
Version: 1.0.2+20011202 (woody)
Version: 1.0-10 (potato)
Upgrade bug potato -> woody
Potato's tetex-base listed /etc/X11/Xresources/tetex-base as a
conffile. But woody's tetex-base doesn't contain a file of this name,
so dpkg does not touch it during potato -> woody upgrade.
It is therefore the job of the tetex-base maintainer scripts to deal
with this file. Currently they do nothing, so the file is cut adrift,
and remains as cruft.
In woody, there is a conffile with the exact same role but the
(better) name /etc/X11/app-defaults/XDvi .
To fix this bug, how about something like the following?
In the postinst (similar to tetex-bin.postinst)
if [ "$1" = "configure" ] && dpkg --compare-versions "$2" lt \
<version-number-of-this-bugfix>;
then
# Handle new name for conffile and clean up an old upgrade bug
oldXconf=/etc/X11/Xresources/tetex-base
newXconf=/etc/X11/app-defaults/XDvi
bakXconf=${newXconf}.dpkg-old
# if old file exists and no other package owns it now (am I paranoid?)
if [ -f $oldXconf ] && ! dpkg -S $oldXconf &> /dev/null ;
then
if [ -f $bakXconf ]; # the existing backup should be enough
then
if rm -f $oldXconf &> /dev/null;
then
echo Obsolete conffile $oldXconf has been removed
else
echo Unable to remove obsolete conffile $oldXconf
fi
elif [ ! -a $bakXconf ];
then
echo New conffile $newXconf replaces $oldXconf
if mv $oldXconf $bakXconf &> /dev/null;
then
echo Existing $oldXconf saved as $bakXconf
else
echo Unable to rename $oldXconf to $bakXconf
fi
fi
fi
fi
---
FIN
---
----- End forwarded message -----
--
see shy jo
Attachment:
pgpp16rzruk8P.pgp
Description: PGP signature