Re: policy changes toward Non-Interactive installation
Hi,
I have a number of serious technical objections to this.
>>"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 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?
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
manoj
--
Be wary of strong drink. It can make you shoot at tax collectors and
miss. Lazarus Long, "Time Enough for Love"
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: