[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

FWD: When conffiles get cut adrift

It it a package's job to deal with moving a conffile if the conffile is

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

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,


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
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 \
   # Handle new name for conffile and clean up an old upgrade bug

   # if old file exists and no other package owns it now (am I paranoid?)
   if [ -f $oldXconf ] && ! dpkg -S $oldXconf &> /dev/null ;
      if [ -f $bakXconf ];  # the existing backup should be enough
         if rm -f $oldXconf &> /dev/null;
            echo Obsolete conffile $oldXconf has been removed
            echo Unable to remove obsolete conffile $oldXconf
      elif [ ! -a $bakXconf ];
         echo New conffile $newXconf replaces $oldXconf
         if mv $oldXconf $bakXconf &> /dev/null;
            echo Existing $oldXconf saved as $bakXconf
            echo Unable to rename $oldXconf to $bakXconf


----- End forwarded message -----

see shy jo

Attachment: pgpp16rzruk8P.pgp
Description: PGP signature

Reply to: