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:
pgpIPTPUvqptx.pgp
Description: PGP signature