Re: policy changes toward Non-Interactive installation
Manoj Srivastava <srivasta@debian.org> writes:
> Hi,
>
> I have a number of serious technical objections to this.
Saying all I mean in one sentence:
I don't want to change one bit of what is done, but when.
> >>"goswin" == goswin brederlow <goswin.brederlow@student.uni-tuebingen.de> writes:
>
> goswin> Installation (apart from configuration) should become
> goswin> absolutly non-interactive. Stopping the unpacking of setting
> goswin> up of packages just because of one package needing the users
> goswin> interaction is anyoing.
>
> Yes, non-interactiveness is nice. But non-breakage is even
> nicer. Decreeing non-interactiveneess in policy is certainly not the
> way to go about it. What needes to be done is an analysis of the
> interaction in various postinsts, and to see if we can come with a
> mechanism, and code, to make sure we can handle all the cases without
> breakage.
I only see 2 things in postinst scripts:
1. configuration
Configuration should use debconf and can be done seperatly from
installing as apt already does.
2. stupid messages telling me something and waiting for return
Those, if realy needed (as they are sometimes) should use debconf
as well, so they can be collected and viewed at the end or send per
mail or whatever debconf chooses to do with them.
> I do believe that a system that works out of the box is worth
> more than a silent install. And to one unfamiliar with the package,
> or even Debian, having one place to note all that requires to be done
> for installation is a good thing. Having parts of the install process
> being punted of to an unsecified later time is not something I would
> like.
>
> 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). Perhaps -devel is
> where this should be while we design a proper mechanism?
So is debconf (apart from being broken at the moment) ready to have
its use forced for woody for user interaction during installation /
configuration? There are only a few packages affected, so its not to
hard to force it.
> Indeed, the end user should be asked whether deferring part of
> the install process is desirable in the first place. I would hate for
> my MTA to be in an unconfigured state until I happen to realize mail
> is not going anywhere.
You misunderstand me still. I want to seperate configuration and
installation. I don't want sshd to be shutdown for hours just because
I need time to configure the MTA. The MTA could ask all it needs via
debconf and then in one big non-interactive go install everything.
> goswin> At the moment Policy encourages the package to display important
> goswin> information and request the user to press return before the
> goswin> installation can continue.
>
> The operative word here is ``important''. Ie, stuff that can
> cause things to break unless acted upon. Policy already frowns upon
> innecesary interaction.
I still suggest that such messages should be handled via debconf and
not by waiting for return. Also note that debconf has several levels
of importance. :)
> goswin> The first thing to mention is that several Packages that need
> goswin> configuration before being run give an error in their
> goswin> /etc/init.d scripts unless one configures them not to. So
> goswin> they don't need to hold up installation to pass this
> goswin> information along. No harm can be done by starting them
> goswin> unconfigured.
>
> I am not so sure. I hate it when I go install a package, and
> find that it does not work -- and that it has failed silently. Having
> a working system Indeed, since I rarely reboot, and maynot even be
> paying attention to the screen while doing so, I may never know this
> failure -- espescially if I am merely managign the machine, and am
> not the user.
>
> A better means of notification is required.
Yes, notification, but not holding up the installation. Just throw the
information at debconf. :) At the moment debconf would still hold up
the installation, but that would be ONE place to change.
> goswin> The second thing is that such information should be collected during
> goswin> install and be displayed in one chunk afterwards (in a series of
> goswin> debconf requesters?).
>
> For purely information messages this would work fine. Not if
> the installation process needs the information to get the package
> into a working state (think what happens if a package being installed
> pre-depends on this apckage).
Those should get preconfigured via debconf.
> goswin> The third thing isn't relevant to the section of ploicy but
> goswin> just as anoying. When a configfile gets updated dpkg will
> goswin> stop and ask the user before it continues. Maybe those
> goswin> requests could be collected as well and be handled
> goswin> seperatly. Those requestst would need the conffile and the
> goswin> restart command needed. They would not need to rerun the
> goswin> postinst again or something similar expensive.
>
> This information could be collected and asked _before_
> starting the installation process, but at that point there is not
> enough data to make an informed decision. I generally like to compare
> what I have, and what dpkg wants to install, before I answer the
> question. So, these questions can't be asked until the package is
> unpacked; and I do not want critical packages to remain in an unknown
> state while the rest of the installation goes on.
>
> Minimal downtime for a package can be critical.
Exactly. So dpkg waiting for you to check the new sendmail
confguration should not stop restarting sshd. I don't want to change
any behaviour, just reorder the times when the things are done.
> goswin> Concluding those 3 points I would tike to propose the following:
>
> goswin> 1. A mechanism should be developed to collect all important
> goswin> information and display them in one chunk.
>
> Providing this can be done at all. Asking about conffiles
> without giving the user a chance to compare the different versions is
> not good.
I just want to put of asking those questions until everything else is
done. That means longer downtime for packages with changed config but
shorter for all else (which is the majority).
> 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.
Do we actually have such a case? In that case debconf would have to
pop up during installation, since the question couldn't be asked
before. Don't think we have such a case.
> This all works under our current mechanisms. How do you handle
> this under the new scheme? When can we ask the questions? Unless we
> are prepared for a larger downtime window, we can't make the process
> non-interactivbe until the end. The user should be able to choose
> which way the installation process goes.
Lets cross that bridge when we come to it. :) I hope we never will.
> goswin> 2. Policy should be changed to encourage the use of debconf for
> goswin> configuration and discourage anything that stops unpacking and setting
> goswin> up of packages until the user does something.
>
> The second part is already inplace. Anything but important
> stuff is frowned upon. The first part, in my opinion, should wait
> until debconf is more widely deployed, but perhaps I am being too
> conservative.
I think the second part should be done via debconf as well. If only
for the more consitent look&feel of it. :) It also catches the eye. On
slow system it can take some time till you notice the screen isn't
scrolling anymore. Lets tunnel all those same events through debconf,
so theres ONE place to handle them differently (like sending them in a
mail for example).
> goswin> 3. dpkg should be changed to collect all conffile changes and handle
> goswin> them in one chunk apart from the unpacking and seting up of other
> goswin> packages.
>
> This is not a great idea. As I said above, it has to be done
> after unpacking the apcjage, so the versions are available to be
> compared, and it shoufl not be too far after unpacking, since the
> package can be potentially in a non-working state. This can be an
> issue for some daemon packages; and ease and robustness of upgrading
> should not be sacrificed for non-interactiveness, no matter how
> laudable that goal is. After all, we have lived with our install
> process this long, we can live with it until we find the correct
> means of achieving that goal.
Whats so bad about holding up the restart of packages that need you
intervention anyway? There should be only a few cases happening and a
lot of other demons would restart a lot sooner. The downtime of those
cases would suffer a bit, the overall downtime will be far less. Also
note that you don't have to go check every 5 minutes if theres a
conffile conflict but just once at the end and then dpkg would ask you
about all conflicts one after another without large delays.
If you realy want to minimize downtime more than this you would have
to fork whenever you hit a conflict, wait for the user and continue at
the same time, but that would be a big change (although one I would
like).
May the Source be with you.
Goswin
Reply to: