On Fri, May 19, 2006 at 11:14:27AM -0400, Christopher Martin wrote:
> There is nothing we can do to control whether the user is prompted or
> not.
>
> In this case, the reason you were prompted (despite not having manually
> altered the file) is probably because the file in question was
> accidentally dropped from the packages some time ago, and only re-added
> with the last upload. Thus the conffile updating mechanisms had no
> record of an original file to compare against the new one, and
> therefore no way to determine whether or not you'd updated the file
> manually, so it erred on the side of caution and prompted you before
> replacing it.
>
> In short, it was not a bug, but a sign of a bug being fixed. It
> shouldn't happen again.
Ah, thanks for the explanation. The source of the problem, then, is
that:
. the conffile got dropped at some point; and,
. when the conffile got restored, it had different content;
actually, this happens even if the version at which the conffile
content changed isn't exactly the version at which it was
restored; if the buggy package not own the conffile was installed
(and the conffile was [deliberately] not removed by dpkg or the
admin), and then the new package (including a new conffile) is
installed
You can actually avoid the conffile prompt, though it may not be worth
it since I think that think doesn't affect stable upgrades (dpkg, by
definition handles conffile content changes gracefully, and
automatically, as long as the package owning the conffile doesn't
change [during the same upgrade as the content of the conffile
changes]).
Just make the preinstall script remove the file if:
1 it is an upgrade (and not a fresh install), from an affected
version
2 the file exists
3 the md5sum of the file matches that stored in the dpkg status
database,
4 the md5sum of the file matches (one of) the expected md5sum(s)
from the affected version(s)
2 is unnecessary if you use rm -f, and 4 is not strictly necessary,
but the world is a better place when there are more conditionals
around a noninteractive rm.
Justin
> On Friday 19 May 2006 09:33, Justin Pryzby wrote:
> > Package: kdebase-bin
> > Version: 3.5.2-2+b1
> > Severity: important
> > File: /etc/pam.d/kscreensaver
> >
> > I didn't make this change, so I should not be prompted about it. I
> > couldn't reproduce it, though, so I'm not filing it as bug..
> >
> > Preparing to replace kdebase-bin 4:3.5.2-1 (using
> > .../kdebase-bin_4%3a3.5.2-2+b1_i386.deb) ...
> > Unpacking replacement kdebase-bin ...
> >
> > [...]
> >
> > Setting up kdebase-bin (3.5.2-2+b1) ...
> > Installing new version of config file /etc/pam.d/kcheckpass ...
> >
> > Configuration file `/etc/pam.d/kscreensaver'
> > ==> File on system created by you or by a script.
> > ==> File also in package provided by package maintainer.
> > What would you like to do about it ? Your options are:
> > Y or I : install the package maintainer's version
> > N or O : keep your currently-installed version
> > D : show the differences between the versions
> > Z : background this process to examine the situation
> > The default action is to keep your current version.
> > *** kscreensaver (Y/I/N/O/D/Z) [default=N] ? D
> >
> > --- /etc/pam.d/kscreensaver 2004-04-11 14:46:01.000000000 -0400
> > +++ /etc/pam.d/kscreensaver.dpkg-new 2006-05-06 21:18:35.000000000
> > -0400 @@ -1,10 +1,6 @@
> > #
> > # /etc/pam.d/kscreensaver - specify the PAM behaviour of
> > kscreensaver #
> > -
> > -# The standard Unix authentication modules, used with
> > -# NIS (man nsswitch) as well as normal /etc/passwd and
> > -# /etc/shadow entries.
> > @include common-auth
> > @include common-account
> > @include common-password
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
