# Severity change pending a mutual agreement of the problem. reopen 326644 thanks
On Tue, Sep 06, 2005 at 06:32:12AM +0300, Guillem Jover wrote: > Hi, > > On Sun, Sep 04, 2005 at 02:13:24PM -0400, Justin Pryzby wrote: > > Package: gpm > > Severity: serious > > Version: 1.19.6-21 > > File: /etc/gpm.conf > > Justification: maintscripts apparently modify conffile (violates: 10.7.3) > > That's wrong. This file is a configuration file, and not a conffile. Okay, but the effect is the same. The intent of policy is that upgrades prompt the user iff: - the conffile is modified by the maintainer (a different version is shipped in a newer version of a package than in an older version, causing the md5sum to change); AND - the conffile which was installed by a previous version of the package being upgraded was locally modified by the administrator. If either of the above are false, then no prompting is necessary, and the upgrade can non-interactively do the expected thing. Is it true that /etc/gpm.conf used to be a conffile? I don't understand any other way that I could be prompted. Agree, that a transition to debconf+ucf could be nontrivial. > Well, even if annoying, we cannot do anything about that, because > that's due to the transition to debconf + ucf, and we cannot fix and > get that into sarge anyway. So I'm closing this bug, if you disagree, > please reopen and lower the severity to normal or similar. A solution exists for any technical problem. Have you seen: http://www.dpkg.org/ConffileHandling Based on my understanding of the situation, an old version of GPM had a conffile, which is now a UCF-handled configuration file, no? If this is correct, I propose that GPM should parse any existing conffile, and determine all the values it sets, and store those values via debconf. This should happen in preinst, I think. Then, in the configure stage, it should prompt the user for any unset values. In postinst, it should use UCF to create a _new_ configuration. > Although that will be pointless as that will not happen anymore on > sarge -> etch upgrade, and Debian only supports upgrading from one > release to the next one. Huh? I upgraded to the GPM that migrated to testing ~2 days ago. So right now it is a "candidate" version for inclusion into etch; if you don't release any new version, then this GPM will probably be the one in etch. What I would like to see is a GPM update which properly handles this UCF transition uploaded to unstable, as the new etch "candidate". Although _I_ will never see the conffile prompt again, everyone else who updates from a sarge gpm to any ucf-enabled gpm will get the prompt, which is something to be avoided. It is an especially big problem during dist-upgrades, when many packages have similar problems. Users shouldn't need to spend massive amounts of time reading diffs only to discover that they are being unnecessarily prompted. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]