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

When debconf is no longer required for a package...



Scenario:
A package has been using debconf successfully for a reasonable time
frame (including one stable release) but develops to a point where the
debconf questions are not only unused but potentially problematic and
could become a source of new bugs. The debconf questions, the
translations of those questions and the config script have all been
removed from the next version of the package (due for upload to
experimental soon). The debconf data and the files in /etc/ that were
used to store the values retrieved from debconf now need to be erased
*not upon purge but upon upgrade|configure*, whenever the old files
still exist. The old version of the package correctly uses a postrm
which only removes this data upon purge - so this doesn't get called
upon upgrade.

I would have thought that the code that used to do this task in the
old postrm could be migrated to a preinst or a postinst in the new
version of the package and tweaked to run under the relevant command. I
don't really mind which and I'm tending towards putting it into the
postinst because the package can configure with these files hanging
around, it just isn't particularly good to leave them around at runtime
- if only because it will confuse the user as so many other things
have changed in the package.

Maybe the solution is to change the postrm to act on upgrade as well as
purge (the old behaviour was just on purge) but then the unwanted files
hang around until every user has upgraded FROM the NEW version.

What I'd really like is a way for the new package to say "purge the old
version before installing this one" because the old version contains
all the necessary code to make a purge work correctly and the new
version wouldn't need any maintainer scripts at all. Maybe I need a
Conflicts: ?

I would have also thought that the package could drop dependencies on
debconf and ucf (which was used to manage the old files) as the
maintainer script can easily check if /usr/bin/ucf exists and whether
debconf exists etc. to purge the relevant data records before removing
the files themselves. (If debconf or ucf have been removed, the package
cannot do anything about the data that debconf|ucf should have deleted
upon their own removal.)

I'm getting lintian warnings:

W: libemdebian-tools-perl: postrm-does-not-purge-debconf
W: libemdebian-tools-perl: missing-debconf-dependency-for-preinst
W: libemdebian-tools-perl: maintainer-script-needs-depends-on-ucf
preinst

I had equivalent warnings when the instructions were in the postinst.

Yes, lintian can be wrong sometimes, but I thought I'd check the logic
here first.

Does the package have to retain debconf and/or ucf forever just because
it used it once? (Or keep the dependencies until the last version to
use the debconf data has gone from oldstable? That seems a tad
excessive and buggy.)

Does the package have to be modified to ignore the files even if they
still exist because the admin might have altered them? (Those
modifications cannot be allowed to have any effect on the new version
of the package because the old configuration is meaningless within the
model used by the new version, so "retaining local changes" has no
meaning in this context. The local changes are buggy by definition.)

Is this just a corner case that lintian doesn't catch? (Is it really so
rare that packages stop using debconf at some future version?) It's
roughly equivalent to a package moving from a database that needed
dbconfig-common support to some other backend (maybe a binary or simple
file based one) that didn't need any debconf configuration. I'd expect
this to have happened before.

The package concerned has changed radically in this new version - 50%
of the previous codebase has been removed and the whole package
operates according to a different model. I'm half tempted to change the
source package name and let it go through NEW again with a Conflicts:
Replaces: against all the old packages, but changing the binary package
names or conflicting against old versions of the same binary package
seemed wrong.

Suggestions?

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/

Attachment: pgpynNAgO6eYw.pgp
Description: PGP signature


Reply to: