On Wed 07 Sep 2005, Frank Küster wrote: > > /etc/cron.d/wwwoffle contains: > > # If you want to disable this, comment out the line > # below (don't simply remove this file).
Note also that your subject is incorrect, it is *not* marked a conffile. It's not even shipped with the package. > 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. Thanks, Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]