gpm: modifies conffile?

[Debian Bug Importer]

Automatically imported from Debian bug report #326644 http://bugs.debian.org/326644

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #326644 http://bugs.debian.org/326644

[Debian Bug Importer (debzilla)]

Message-ID: <20050904181324.GA12789@andromeda>
Date: Sun, 4 Sep 2005 14:13:24 -0400
From: Justin Pryzby <email address hidden>
To: Debian BTS Submission <email address hidden>
Subject: gpm: modifies conffile?

Package: gpm
Severity: serious
Version: 1.19.6-21
File: /etc/gpm.conf
Justification: maintscripts apparently modify conffile (violates: 10.7.3)

While doing a dist upgrade:

  Preparing to replace gpm 1.19.6-20 (using .../gpm_1.19.6-21_i386.deb) ...
  Unpacking replacement gpm ...

I got a message about /etc/gpm.conf being modified:

  --- /etc/gpm.conf 2003-04-26 20:36:28.000000000 -0400
  +++ /tmp/tmp.vMywl5 2005-09-04 12:58:51.000000000 -0400
  @@ -9,12 +9,12 @@
   # protected from evaluation (i.e. by quoting them).
   #
   # This file is used by /etc/init.d/gpm and can be modified by
  -# /usr/sbin/gpmconfig.
  +# "dpkg-reconfigure gpm" or by hand at your option.
   #
   device=/dev/input/mice
   responsiveness=
   repeat_type=
   type=autops2
  -append=""
  +append=''
   sample_rate=

GPM/Debconf reports that "my version" (of the file) "has been locally
modified", but was not modified by me.

[Guillem Jover (guillem)]

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.

> While doing a dist upgrade:
>
> Preparing to replace gpm 1.19.6-20 (using .../gpm_1.19.6-21_i386.deb) ...
> Unpacking replacement gpm ...
>
> I got a message about /etc/gpm.conf being modified:
>
> --- /etc/gpm.conf 2003-04-26 20:36:28.000000000 -0400
> +++ /tmp/tmp.vMywl5 2005-09-04 12:58:51.000000000 -0400
> @@ -9,12 +9,12 @@
> # protected from evaluation (i.e. by quoting them).
> #
> # This file is used by /etc/init.d/gpm and can be modified by
> -# /usr/sbin/gpmconfig.
> +# "dpkg-reconfigure gpm" or by hand at your option.
> #
> device=/dev/input/mice
> responsiveness=
> repeat_type=
> type=autops2
> -append=""
> +append=''
> sample_rate=
>
> GPM/Debconf reports that "my version" (of the file) "has been locally
> modified", but was not modified by me.

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

regards,
guillem

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 6 Sep 2005 06:32:12 +0300
From: Guillem Jover <email address hidden>
To: Justin Pryzby <email address hidden>,
 <email address hidden>
Subject: Re: Bug#326644: gpm: modifies conffile?

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.

> While doing a dist upgrade:
>
> Preparing to replace gpm 1.19.6-20 (using .../gpm_1.19.6-21_i386.deb) ...
> Unpacking replacement gpm ...
>
> I got a message about /etc/gpm.conf being modified:
>
> --- /etc/gpm.conf 2003-04-26 20:36:28.000000000 -0400
> +++ /tmp/tmp.vMywl5 2005-09-04 12:58:51.000000000 -0400
> @@ -9,12 +9,12 @@
> # protected from evaluation (i.e. by quoting them).
> #
> # This file is used by /etc/init.d/gpm and can be modified by
> -# /usr/sbin/gpmconfig.
> +# "dpkg-reconfigure gpm" or by hand at your option.
> #
> device=/dev/input/mice
> responsiveness=
> repeat_type=
> type=autops2
> -append=""
> +append=''
> sample_rate=
>
> GPM/Debconf reports that "my version" (of the file) "has been locally
> modified", but was not modified by me.

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

regards,
guillem

[Justin Pryzby (justinpryzby-users)]

# 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

[Peter Samuelson (peter-p12n)]

[Justin Pryzby]
> 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.

In fact, this is *exactly* what gpm does.
Have you got any other bright ideas?

[Justin Pryzby (justinpryzby-users)]

On Tue, Sep 06, 2005 at 11:15:36AM -0500, Peter Samuelson wrote:
>
> [Justin Pryzby]
> > 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.
>
> In fact, this is *exactly* what gpm does.
> Have you got any other bright ideas?
Then why does it prompt me? Does prerm remove the conffile after
parsing it?

Justin

[Peter Samuelson (peter-p12n)]

[Justin Pryzby]
> Then why does it prompt me? Does prerm remove the conffile after
> parsing it?

That's a really good question. ucf is supposed to take care of this
type of stuff - knowing when a config file was changed by the admin and
when it was only changed by the package. ucf support appeared in gpm
1.19.6-15, over a year ago (and yes, gpm ucf support is in sarge), so I
don't think your bug is related to the transition from conffile to ucf.

Smells like a bug in ucf itself, but if so, I wonder why it doesn't hit
other users and other packages. My understanding is very incomplete at
this time.

[Debian Bug Importer (debzilla)]

Message-ID: <20050906155622.GB3655@andromeda>
Date: Tue, 6 Sep 2005 11:56:23 -0400
From: Justin Pryzby <email address hidden>
To: Guillem Jover <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#326644: gpm: modifies conffile?

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 6 Sep 2005 11:15:36 -0500
From: Peter Samuelson <email address hidden>
To: Justin Pryzby <email address hidden>,
 <email address hidden>
Subject: Re: Bug#326644: gpm: modifies conffile?

--vIXBmblrD40XNCy4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

[Justin Pryzby]
> 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.

In fact, this is *exactly* what gpm does.
Have you got any other bright ideas?

--vIXBmblrD40XNCy4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHcCoXk7sIRPQRh0RAgqEAJ4j7IPXIh7YyG5J5cYe/F1oYlLppgCfTmSc
WFRF9Xd2dsec0XOf7KdaQr0=
=3R9P
-----END PGP SIGNATURE-----

--vIXBmblrD40XNCy4--

[Debian Bug Importer (debzilla)]

Message-ID: <20050906163546.GD3655@andromeda>
Date: Tue, 6 Sep 2005 12:35:46 -0400
From: Justin Pryzby <email address hidden>
To: Peter Samuelson <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#326644: gpm: modifies conffile?

On Tue, Sep 06, 2005 at 11:15:36AM -0500, Peter Samuelson wrote:
>
> [Justin Pryzby]
> > 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.
>
> In fact, this is *exactly* what gpm does.
> Have you got any other bright ideas?
Then why does it prompt me? Does prerm remove the conffile after
parsing it?

Justin

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 6 Sep 2005 11:49:23 -0500
From: Peter Samuelson <email address hidden>
To: Justin Pryzby <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#326644: gpm: modifies conffile?

--tV/+6PImfyFtriLg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

[Justin Pryzby]
> Then why does it prompt me? Does prerm remove the conffile after
> parsing it?

That's a really good question. ucf is supposed to take care of this
type of stuff - knowing when a config file was changed by the admin and
when it was only changed by the package. ucf support appeared in gpm
1.19.6-15, over a year ago (and yes, gpm ucf support is in sarge), so I
don't think your bug is related to the transition from conffile to ucf.

Smells like a bug in ucf itself, but if so, I wonder why it doesn't hit
other users and other packages. My understanding is very incomplete at
this time.

--tV/+6PImfyFtriLg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHciTXk7sIRPQRh0RAlhHAKC9D1dZ8//Cty0fRHoXhepu5gd8EwCgzOwB
ADwf90QOoux7iGAhQKxFLZA=
=HSH1
-----END PGP SIGNATURE-----

--tV/+6PImfyFtriLg--

[Guillem Jover (guillem)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 7 Sep 2005 02:48:58 +0300
From: Guillem Jover <email address hidden>
To: Justin Pryzby <email address hidden>,
 <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#326644: gpm: modifies conffile?

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

[Justin Pryzby (justinpryzby-users)]

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

[Peter Samuelson (peter-p12n)]

package gpm
severity 326644 normal
thankee

[Guillem Jover]
> 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?

Right. As far as I know we correctly preserve local admin settings.
That's what Policy requires. This bug is merely an annoyance when you
upgrade, it doesn't actually cause any harm.

Changing severity to 'normal' accordingly.

I also agree about wontfix; see later reply.

Peter

[Peter Samuelson (peter-p12n)]

[Justin Pryzby]
> 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?

Correct. And that is exactly what we do. And the simplest way to take
into account changes the user makes with debconf is to rewrite the file
in postinst unconditionally. This, too, we do. This also keeps the
file comments in sync with our latest version, which is in general a
Good Thing. (You may have noticed the comment update telling you to
use dpkg-reconfigure rather than gpmconfig. That comment is for your
benefit, not ours.)

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

Won't help. We cannot tell the difference, as Guillem said, between a
file converted to ucf in sarge and later modified by hand, and a file
converted to ucf in sarge and *not* later modified by hand.

The only thing we could fix would be upgrades from woody to present
day. And that isn't particularly supported anyway (although in the
case of gpm, it will work), so I don't see much point.

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

Right, you don't understand. See above for why this would have to be
fixed in sarge (which means it will not happen).

> As above, isn't the md5sum of the previous nonucf file known?

What md5sum? The one corresponding to the woody /etc/gpm.conf on your
computer? How would we know whether that was locally modified or not?
We don't.

We didn't even know *at the time* whether the config file was "modified
locally". The gpmconfig script could be run independently of the
postinst, and in any case it did not record what md5sum the file had
when last written out. debconf + ucf is a great improvement in that
regard.

Peter

[Debian Bug Importer (debzilla)]

Message-ID: <20050907023032.GA3687@andromeda>
Date: Tue, 6 Sep 2005 22:30:32 -0400
From: Justin Pryzby <email address hidden>
To: Guillem Jover <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#326644: gpm: modifies conffile?

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 6 Sep 2005 21:40:46 -0500
From: Peter Samuelson <email address hidden>
To: Guillem Jover <email address hidden>, <email address hidden>,
 Justin Pryzby <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#326644: gpm: modifies conffile?

--1IOPqZ3f1xe/JZlz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

package gpm
severity 326644 normal
thankee

[Guillem Jover]
> 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?

Right. As far as I know we correctly preserve local admin settings.
That's what Policy requires. This bug is merely an annoyance when you
upgrade, it doesn't actually cause any harm.

Changing severity to 'normal' accordingly.

I also agree about wontfix; see later reply.

Peter

--1IOPqZ3f1xe/JZlz
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHlMuXk7sIRPQRh0RAh1tAJ0U8LMlbytX/IsygJQNRnwC+H6IlACfVatM
beZO9VeVY4Fkb2dL1Gt91nU=
=TGYv
-----END PGP SIGNATURE-----

--1IOPqZ3f1xe/JZlz--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 6 Sep 2005 21:54:09 -0500
From: Peter Samuelson <email address hidden>
To: Justin Pryzby <email address hidden>,
 <email address hidden>
Subject: Re: Bug#326644: gpm: modifies conffile?

--OowMmFE4aK71mEhh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

[Justin Pryzby]
> 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?

Correct. And that is exactly what we do. And the simplest way to take
into account changes the user makes with debconf is to rewrite the file
in postinst unconditionally. This, too, we do. This also keeps the
file comments in sync with our latest version, which is in general a
Good Thing. (You may have noticed the comment update telling you to
use dpkg-reconfigure rather than gpmconfig. That comment is for your
benefit, not ours.)

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

Won't help. We cannot tell the difference, as Guillem said, between a
file converted to ucf in sarge and later modified by hand, and a file
converted to ucf in sarge and *not* later modified by hand.

The only thing we could fix would be upgrades from woody to present
day. And that isn't particularly supported anyway (although in the
case of gpm, it will work), so I don't see much point.

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

Right, you don't understand. See above for why this would have to be
fixed in sarge (which means it will not happen).

> As above, isn't the md5sum of the previous nonucf file known?

What md5sum? The one corresponding to the woody /etc/gpm.conf on your
computer? How would we know whether that was locally modified or not?
We don't.

We didn't even know *at the time* whether the config file was "modified
locally". The gpmconfig script could be run independently of the
postinst, and in any case it did not record what md5sum the file had
when last written out. debconf + ucf is a great improvement in that
regard.

Peter

--OowMmFE4aK71mEhh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHlZRXk7sIRPQRh0RAraCAJ9DR2XCLwS/heEowjuSwg40G3Zs5wCbB41X
m/OqUyHoBTRMMsKLDwKtTas=
=gcWO
-----END PGP SIGNATURE-----

--OowMmFE4aK71mEhh--

[Justin Pryzby (justinpryzby-users)]

On Tue, Sep 06, 2005 at 09:54:09PM -0500, Peter Samuelson wrote:
>
> [Justin Pryzby]

> > > 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?
>
> Won't help. We cannot tell the difference, as Guillem said, between a
> file converted to ucf in sarge and later modified by hand, and a file
> converted to ucf in sarge and *not* later modified by hand.
Are you talking about the case that the file is at some defualt-ish
"version" 1, then updated to v2, then to v3, and then the admin
manually "updates" in such a way that it happens to be identical to
v2?

> > As above, isn't the md5sum of the previous nonucf file known?
>
> What md5sum? The one corresponding to the woody /etc/gpm.conf on your
> computer?
woody? I haven't run woody on this machine in forever .. possibly
never. The file might have been "the one woody used" though, I guess.

Justin

[Debian Bug Importer (debzilla)]

Message-ID: <20050907084404.GA13421@andromeda>
Date: Wed, 7 Sep 2005 04:44:04 -0400
From: Justin Pryzby <email address hidden>
To: Peter Samuelson <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#326644: gpm: modifies conffile?

On Tue, Sep 06, 2005 at 09:54:09PM -0500, Peter Samuelson wrote:
>
> [Justin Pryzby]

> > > 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?
>
> Won't help. We cannot tell the difference, as Guillem said, between a
> file converted to ucf in sarge and later modified by hand, and a file
> converted to ucf in sarge and *not* later modified by hand.
Are you talking about the case that the file is at some defualt-ish
"version" 1, then updated to v2, then to v3, and then the admin
manually "updates" in such a way that it happens to be identical to
v2?

> > As above, isn't the md5sum of the previous nonucf file known?
>
> What md5sum? The one corresponding to the woody /etc/gpm.conf on your
> computer?
woody? I haven't run woody on this machine in forever .. possibly
never. The file might have been "the one woody used" though, I guess.

Justin

[Peter Samuelson (peter-p12n)]

[Justin Pryzby]
> Are you talking about the case that the file is at some defualt-ish
> "version" 1, then updated to v2, then to v3, and then the admin
> manually "updates" in such a way that it happens to be identical to
> v2?

I'm saying we can't tell whether you modified the file since it was
last touched by gpmconfig. gpmconfig did not record this information.
When we switched to ucf, we did not at the same time record what your
old file's md5sum was. But if you *had* made local modifications to
the file by hand, recording the md5sum would have been the wrong thing
to do anyway.

There's a reason we switched to ucf. To get away from this madness.

> > What md5sum? The one corresponding to the woody /etc/gpm.conf on
> > your computer?
> woody? I haven't run woody on this machine in forever .. possibly
> never. The file might have been "the one woody used" though, I
> guess.

The interval between woody and sarge is not all that interesting. gpm
was changed to use debconf and ucf very late in the sarge release
cycle. So when I say sarge, I mean sarge as of the last 6 months or
less before its release. If you were running sarge before that, your
gpm version at the time would have been very similar to woody's.

This discussion isn't going anywhere. We have marked the bug 'wontfix'
for, we think, good reasons. I think the best way to change our minds
is to post a tested and working patch. I have my doubts that such a
patch is even *possible*, without hitting a sort of inverse of this bug
(hitting a false negative instead of a false positive, and overwriting
local admin changes silently). Which would be quite a bit worse.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 7 Sep 2005 05:35:01 -0500
From: Peter Samuelson <email address hidden>
To: Justin Pryzby <email address hidden>,
 <email address hidden>
Subject: Re: Bug#326644: gpm: modifies conffile?

--dXvu6+ixFx2ZffE8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

[Justin Pryzby]
> Are you talking about the case that the file is at some defualt-ish
> "version" 1, then updated to v2, then to v3, and then the admin
> manually "updates" in such a way that it happens to be identical to
> v2?

I'm saying we can't tell whether you modified the file since it was
last touched by gpmconfig. gpmconfig did not record this information.
When we switched to ucf, we did not at the same time record what your
old file's md5sum was. But if you *had* made local modifications to
the file by hand, recording the md5sum would have been the wrong thing
to do anyway.

There's a reason we switched to ucf. To get away from this madness.

> > What md5sum? The one corresponding to the woody /etc/gpm.conf on
> > your computer?
> woody? I haven't run woody on this machine in forever .. possibly
> never. The file might have been "the one woody used" though, I
> guess.

The interval between woody and sarge is not all that interesting. gpm
was changed to use debconf and ucf very late in the sarge release
cycle. So when I say sarge, I mean sarge as of the last 6 months or
less before its release. If you were running sarge before that, your
gpm version at the time would have been very similar to woody's.

This discussion isn't going anywhere. We have marked the bug 'wontfix'
for, we think, good reasons. I think the best way to change our minds
is to post a tested and working patch. I have my doubts that such a
patch is even *possible*, without hitting a sort of inverse of this bug
(hitting a false negative instead of a false positive, and overwriting
local admin changes silently). Which would be quite a bit worse.

--dXvu6+ixFx2ZffE8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHsJVXk7sIRPQRh0RAu9oAJ4nFh9nUqDhloelhchDw31IpgRJGwCfey7e
0Epu9d6PIpEqnIifJliORjo=
=ITuJ
-----END PGP SIGNATURE-----

--dXvu6+ixFx2ZffE8--

[Tollef Fog Heen (tfheen)]

This probably doesn't affect us, and is an universe package, so closing.

[Guillem Jover (guillem)]

Hi,

On Wed, 2005-09-07 at 02:48:58 +0300, Guillem Jover wrote:
> package gpm
> tag 326644 wontfix sarge
> retitle 326644 gpm: ucf considers non-ucf config file manually modified
> thanks

I'm closing this now given that sarge is now oldstable.

regards,
guillem

[Debbugs Internal Request (owner-bugs)]

# A New Hope
# A log time ago, in a galaxy far, far away
# something happened.
#
# Magically this resulted in the following
# action being taken, but this fake control
# message doesn't tell you why it happened
#
# The action:
# Bug archived.
thanks
# This fakemail brought to you by your local debbugs
# administrator