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

[Justin Pryzby]

On Wed, Sep 07, 2005 at 02:48:58AM +0300, Guillem Jover wrote:
> On Tue, Sep 06, 2005 at 11:56:23AM -0400, Justin Pryzby wrote:
> > 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/.
Hmm.  dpkg automatically handles it for conffiles.  I suppose what you
mean is that, for configuration files, admin changes must not be lost
on upgrade.  Instead, the file should be parsed, possibly storing the
values temporarily via debconf database, and the file rewritten, if
necessary.  Right?

> > 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.
I don't follow any implications of what you say..

> 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.
Can you fix it in the preinst, by adding it now?

> 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).
I don't understand..  It affected _me_, upgrading from post-sarge
testing machine to currents testing.  AFAICT that implies that it will
affect other users upgrading from sarge to etch, when it is released
as such, unless something is changed to close this bug.

> 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.
As above, isn't the md5sum of the previous nonucf file known?

> 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.
I can't claim to understand all that you say.  I've never played with
UCF, myself.  wontfix would make sense, if it is a woody=>sarge issue,
as I agree that such a thing is not fixable.  But, it affected me 2
days ago, so it seems to me that something still needs to be fixed.

Justin