On 27 Jun 2002, Konstantin Riabitsev wrote:
> On Thu, 2002-06-27 at 10:32, Robert G. Brown wrote:
> > This is consistent with what I was suggesting, except that when running
> > yum interactively (the state where it asks questions like: "Do you like
> > this list of files and should I proceed?") one could conceivably insert
> > messages like "I can't find these two rpm's, but nothing else depends on
> > them -- do you want to proceed anyway and find the missing rpm's on your
> > own?" with a y/n answer.
>
> How about:
>
> "I can't find these two rpm's, but nothing else depends on them -- do
> you want to proceed anyway and find the missing rpm's on your own?
^^^^^^^^^^^^^^
> "Y/n". You answer "y", after which it...
proceeds to install everything it DOES know how to install and then
> ...drops you into shell and lets you
> fix things using wget and rpm? :)
>
> I'd far rather see yum be a maintenance tool and not "anaconda's little
> brother".
I agree. It should also have clearly demarked interactive and
noninteractive modes -- when invoked in a nightly cron script it should
have a flag of some sort that indicates that itn't to run interactively
and off options that require a keystroke response AND that it needs to
direct or copy at least its stderr if not all its output to syslog.
That way Seth's requirement of never breaking things in a nightly update
is satisfied, because in non-interactive mode it always dies with a
message if it can't run "perfectly" within its tolerance (e.g. maybe a
mirror/secondary host is ok, but no missing files or headers or anything
else that would make the resulting update less than perfect).
Run interactively, there are lots of places where one could add helper
interactive sequences designed to encapsulate solutions to some simple,
common problems and to guide novices towards a better understanding of
how to avoid the problems in a noninteractive run. upgrades, for
example, should always be interactive because of the high probability of
some sort of user choice or intervention. updates, on the other hand,
might well happen either way, and if a non-interactive nightly run
fails, the first thing to try is probably to run yum again
interactively, in the hopes that whatever problem that was encountered
can be resolved by one of the choices interactive operation offers AND
that the user can learn from the option how to make the automated
operation work reliably again.
This is a very reasonable and time-tested model. fsck worked (probably
still works, although ext3 makes it less necessary:-) this way --
anything that it couldn't handle in a noninteractive boot-time check
required an interactive run to hand-fix the problems it found, hopefully
restoring a state where noninteractive fsck'd clean once again.
It also provides a scalable way to insert new "helper" scriptlets
designed to step users through specific problems if and when it is
determined that doing so is less work than helping new users that
inevitably encounter the problems.
rgb
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
