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.

> > 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.
> 
> If that happens, you didn't write the config script as debconf-devel
> advices.  The way to go is to parse the configuration (does the file
> exist? If yes, which interval does it specify?) and put these values
> into the debconf database via db_set, then ask the questions, then in
> postinst db_get the answers and make the changes, if needed.  This is
> all described in debconf-devel(7), under "Config file handling".

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. Help! :)
What to do?

> > 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.
> 
> 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.

> 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).


Paul Slootman


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

Reply via email to