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: