[Pkg-gpm-devel] Bug#326644: gpm: modifies conffile?

Guillem Jover guillem at debian.org
Tue Sep 6 23:48:58 UTC 2005


package gpm
tag 326644 wontfix sarge
retitle 326644 gpm: ucf considers non-ucf config file manually modified
thanks

Hi,

On Tue, Sep 06, 2005 at 11:56:23AM -0400, Justin Pryzby wrote:
> # 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:
> > 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.

s/conffile/configuration file/.

> 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.

No, it has not been a conffile ever. It was a configuration file
on woody and it is on sarge through sid.

> Agree, that a transition to debconf+ucf could be nontrivial.

It only transitioned from being generated with a script (gpmconfig)
to be handled with ucf+debconf, and that happened on sarge. The
transition was pretty easy.

> > 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.

(See at the end).

> A solution exists for any technical problem.
>
> Have you seen:
> 
>   http://www.dpkg.org/ConffileHandling

That does not help. As I've said several times it has not been a
conffile ever.

> > 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.

The version in sarge is 1.19.6-19sarge1, the one you upgraded from was
1.19.6-20. The one now on etch and sid is 1.19.6-21. Debconf support
got introduced in version 1.19.6-14, ucf support got introduced in
1.19.6-15.

The problem here is that we didn't forcibly add the md5sum of the
previous non-ucf file to the ucf database. So it was marked as
modified, then you didn't install any new config file version handled
by ucf, so it kept thinking it was manually generated. And now is too
late to fix that as that needed to be done on the upgrade from woody
to sarge, which we cannot fix anymore (as I've said earlier). So users
have had to deal with this. And once an ucf version is installed we
cannot distinguish between a modified version and a previous non-ucf
file.

Marking this bug wontfix, but I don't really see the point in keeping
this open, and I think that RC is an exaggeration on the magnitude of
the problem. Peter?

regards,
guillem




More information about the Pkg-gpm-devel mailing list