On Tue, Aug 15, 2000 at 08:26:50PM -0700, Joey Hess wrote:
> Anthony Towns wrote:
> > Basically, I'd like to be able to insist that I'm *never* asked a question
> > as part of a postinst. I'd rather the postinst fail (and I'd rather Apt/Dpkg
> > just get on with installing everything else, although it probably won't at
> > the moment) than get asked a question.
> That's do-able. Once debconf knows to run postinsts in full
> noninteractive mode, critical questions that are thus not asked at all,
> and which do not have their return code caught, will simply cause the
> postinst to terminate with a nonzero return code.
>
> (I think this is better than making _all_ questions terminate it, which is
> not doable anyway, and also because if a postinst asks a priority low
> question, say, then that is by definition a question that the
> noninteractive mode can supply a reasonable answer to.)
Well, no, that's not what I want either: I like seeing every question
that the postinst thinks I might need to know about. I just want to see
them in blocks, preferably beforehand, but at the end if that's the way
it has to be.
I don't think we've got any examples of non-critical questions that need
to be outside the .config though, do we? "Something bad happened", and
"You need to stick a floppy in" don't strike me as things that should just
be ignored.
> I'll be happy to implement a debconf/non-interactive-foo (should apply
> to all maintainer scripts save config, not just postinst, so I need a
> better name), if people think it will be generally useful.
non-interactive-install, perhaps? -maintainer-scripts?
> However, I presonally feel your specific case of the floppy prompting
> would be better served by:
> a) Making the question of low priority.
> or
> b) Making the question be asked only once, and this value used by all
> future kernel packges you install. Or adding a question, "do you ever
> want to make a boot floppy?"
> Especially b.
I'm curious about your opinion of an option (c): make a separate
mk-boot-floppy script that can be run outside of the postinst after
the install.
This is the same as what Manoj suggested for realplayer. A bad thing is
that, alone, it's not really automatic, you could install the kernel
and forget to make a boot-floppy, or you could install realplayer and
forget to do what's necessary to actually, well, install realplayer. I
think it's more `user-friendly' in general though: realplayer can be
annoying the way it is at the moment, and I might change my mind and
what a boot floppy later.
Ways of getting around the `not really automatic' problem might be:
* ask a question in the .config whether you want the program to
be run in postinst
* always run the programs after dpkg's finished, like update-menus
* send a reminder email to root
Note that this means the program probably can't really use debconf to
do its stuff if it's separate, ie, we'd suddenly be back to boring text
prompts and such. Or maybe it's reasonable for some non-maintainer-scripts
to use debconf, I suspect it's actually possible at the moment.
Having it as a separate program run after dpkg has finished would let you
have non-interactive maintainer scripts for all the examples I've seen,
I think.
Yes, I realise this won't be implemented by the end of the week. :)
Oh.
Actually...
I imagine that if we ever get post-dpkg-run hooks, they'll be invoked
something like:
run-after-dpkg /usr/bin/update-menus
and be run through sort | uniq or something before being called. It might
be possible to just implement run-after-dpkg to just run immediately for
the moment. Or to re-enable interactive-postinsts, run it, and disable it.
Ripping out the logic from update-menus and implementing it as
run-after-dpkg could probably work pretty easily too, but wouldn't leave
us with anywhere for stdio to happen, afaict [0].
Cheers,
aj
[0] Although a Unix domain socket could help here ;)
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgpKJfvXcaqWq.pgp
Description: PGP signature