Re: policy changes toward Non-Interactive installation
Manoj Srivastava wrote:
> If there is an alternate mechanism in place it would be time
> to make it policy. But debconf is not required yet, and it may not
> fit all potential cases anyway (more on it below).
I read your entire message and could not find any examples of things
that debconf cannot handle correctly, except of course for conffile
change prompting, which it was never designed to do.
If you have some specific complaints with debconf's design, please post
them, but I'm rather confused about what you're talking about right now,
especially since your whole message was very non-specfic and I often
couldn't tell if you were talking about whatever Goswin was talking about,
or about debconf.
> How about this scenario: Package A needs to run a program from
> Package B, and let the user choose between alternatives in order to
> configure package A to be in a working state. Unfortunately, the
> alternatives are not known before the program is run. Package A is a
> daemon process, so we stop the daemon before unpacking, and we start
> it after configuring. We pre-depend on package B, so that our program
> is available to us.
Yes, debconf can handle this, with no behavior changes *at all* from how
it would have traditionally been done.
--
see shy jo
Reply to: