On Wed 05 Apr 2006, Frank Küster wrote: > Paul Slootman <[EMAIL PROTECTED]> wrote: > > > On Wed 05 Apr 2006, Frank Küster wrote: > >> Paul Slootman <[EMAIL PROTECTED]> wrote: > >> > >> > 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... > >> > >> Because debconf is not a registry. It's a frontend for maintainer > >> scripts to interact with local admins, but the actuall *settings* are > >> stored in /etc/. > > > > I'm talking about the case where you just entered a value, > > interactively. > > But I may have changed my mind, and i shouldn't be forced to use debconf > then. No, I *mustn't* be forced.
I'm talking about someone who wants to use debconf... He chose at one time to have the fetching active, removed the cron.d script later, and then changed his mind again, and thinks he can reactivate it via debconf. > > As I said above: I'm talking about the case where you just entered a > > value, interactively. Say, the configuration is parsed (the cron.d file > > is missing, so debconf is seeded with "never"), the user changes that to > > every 30 minutes, hence expects that from that moment on wwwoffle will > > fetch its list every 30 minutes. However, you demand that the postinst > > should never recreate the cron.d file, as the user removed it. > > No, I don't demand that. I only demand that the postinst script not > create the file unconditionally. If a debconf question is seeded with > "no", asked or not, and the postinst script acts according to the > answer, everything is fine. I read your bug report to mean that if the user removes the file, postinst should never, ever recreate it again, because that's what the user wants, otherwise he wouldn't have removed the file. And that's what I have a problem with, because that would mean that if he does dpkg-reconfigure again and enters a fetch frequency, "I" (the postinst script) wouldn't be allowed to create the file again. Your exact words were "and indeed the postinst scripts recreates the file if it has been deleted.", indicating that was the problem. You didn't qualify that statement with "unconditionally" or so... > >> This case can easily be distinguished because, like a postinst, config > >> gets a second parameter which is the version number of the > >> last-configured (i.e. the currently installed) package. If it's a fresh > >> install, $2 is empty. > > > > No, it's freshly installed, but the user runs dpkg-reconfigure because > > he wants to turn on the fetch feature, which he didn't turn on during > > the initial install; that's the situation I meant to demonstrate; sorry > > if that wasn't clear. > > So, where's the problem? He's asked the question, changes from "no" to > "yes" and a specific value, and the change is done - or he doesn't > change, either because he doesn't want to, or he doesn't see the > questions, and no change is done. My problem is with the wording of your bug report, you demand the file mustn't be recreated. If you now qualify that by saying that if the user does indeed enter a frequency again then it's OK to recreate the file, then I indeed don't have a problem anymore. > >> I'd offer to write a patch if you don't want to, or don't have time to > >> dig into this. > > > > If you could take into account all possible situations... then please. > > Note that I am in the process of packaging 2.9, and the maintainer > > script will be changed a lot (I'm taking out support for upgrading from > > before woody, which will simplify things and which should be more than > > enough). > > Is the new maintainer script available somewhere? Not yet. Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
