On Wed, Apr 05, 2006 at 03:50:48PM +0200, Paul Slootman wrote:
> On Wed 07 Sep 2005, Frank K?ster wrote:
> > and indeed the postinst scripts recreates the file if it has been
> > deleted.  However, the policy says clearly:
> > 
> > ,----
> > | 10.7.3 Behavior
> > | 
> > | Configuration file handling must conform to the following behavior:
> > | 
> > |     * local changes must be preserved during a package upgrade, and
> > |     * configuration files must be preserved when the package is
> > |       removed, and only deleted when the package is purged.
> > `----
> > 
> > Local modifications also include file deletion.  You can't override this
> > rule by simply saying "don't do that".
> 
> That same paragraph also states:
> 
> ,---
> | If the existence of a file is required for the package to be sensibly
> | configured it is the responsibility of the package maintainer to
> | provide maintainer scripts which correctly create, update and maintain
> | the file and remove it on purge.
> `---
> 
> If you enter a value via the debconf dialog that indicates that wwwoffle
> should regularly fetch its list, then why remove the cron.d entry...
> If I left that file alone when someone removed it, I'd get critical bug
> reports that the functionality is broken because even after repeated
> dpkg-reconfigure attempts at entering a fetch frequency, it doesn't
> fetch anything.
> 
> Please tell me how I should resolve this dilemma. Please don't just say
> "if it's removed, don't recreate it"; give me some pseudo-code on how to
> handle the different situations.  I find it difficult to distinguish the
> following two situations:
> 
> - wwwoffle is freshly installed, there is and has never been a
>   /etc/cron.d/wwwoffle file, and the user runs dpkg-reconfigure and
>   enters a fetch frequency.
> 
> - wwwoffle was already installed, there was a fetch frequency defined,
>   but now the user has removed the /etc/cron.d/wwwoffle file and now
>   re-runs dpkg-reconfigure.
debconf-devel(7) says that the configure script ("./debian/config") is
passed the same 2 arguments that the postinst gets, so you can tell
whether it is an initial installation, or an upgrade.  If it an
initial installation, then you should recreate the file.  If it is an
upgrade, and if the file doesn't exist, then you might consider
prompting the user "should it be recreated?", and, then, iff they
respond "yes", continue to ask questions, and rewrite the file.  If it
is an upgrade, and the file does exist, then you should both ask the
normal questions and rewrite the file.

Does this do what you need for the package?
Frank, does it seem reasonable to you?

The only gripe I have with this is that it could be considered an overuse of
debconf.

Justin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to