[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problems with using debconf in init script...

On Tue, 13 Feb 2001, Matt Zimmerman wrote:

> Date: Tue, 13 Feb 2001 01:07:31 -0500
> From: Matt Zimmerman <mdz@debian.org>
> To: Manfred Wassmann <manolo@ncc-1701.b.shuttle.de>
> Subject: Re: Problems with using debconf in init script...

Sorry, I dropped that off the list, I'll cc it back now.

> On Tue, Feb 13, 2001 at 06:37:25AM +0100, Manfred Wassmann wrote:
> > On Fri, 2 Feb 2001, Matt Zimmerman wrote:
> > > No, I don't.  I don't think that the config script was expected to do these
> > > kinds of things.  Questions can be asked or skipped based on the answers to
> > > other questions, but doing so based on other attributes of the system
> > > (filesystem objects, running processes, whatever) seems a little shaky.
> > > 
> > 
> > How about recording a timestamp when the config script is run. Then, in
> > the postinst script, write a new conffile to <conffile>.dpkg-new and then
> > check if there exists a conffile that has a modification time later than
> > the recorded timestamp and in that case only ask the user what to do. 
> This is easy enough to do, but duplicates a lot of code in almost every package
> that uses debconf.  Further, consider packages which have many config files,
> and must store timestamps for all of them.  I have proposed that this code be

Well, that is not true, you just have one timestamp which is made when
the debconf script has successfully completed.
I have rethought it and with the template and config unchanged I would do
it in the postinst like this now:

db_get package/timestamp || true
stamp=`date --date="19700101 UTC + $RET seconds" +%Y%m%d%H%M.%S`

and then do a touch -t $stamp on every conffile. then you could simply
test ! $newconf -nt $oldconf

You could then still test if $oldconf file is different from $newconf.
But this approach would have the advantage, that you don't have to access
the conffiles at the time when the debconf script is run.

> added to debconf, or at least debhelper, to keep it in one place and keep
> maintainers from implementing it wrong.  That is how the conffile mechanism
> works, and I think we should try to emulate that.

Of course it is better when the code is in debconf/debhelper.

PGP and GnuPG public keys available at http://germany.keyserver.net
PGP: 24B81049 Fingerprint: D7 10 EE 2B 74 16 C0 64  B4 5F BA B2 90 29 3D AF
GPG: 6B299971 Fingerprint: A598 A41F 57A3 5D69 83D2  8027 1274 F8CD 6B29 9971
+++ United States of America ... where you can get elected with less votes +++

Reply to: