On 27 Jun 2002, Konstantin Riabitsev wrote:
> On Thu, 2002-06-27 at 11:25, Robert G. Brown wrote:
> > > "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? :)
>
> Eww, that would be analogous to passing a "--force" to rpm, which is a
> big, nasty, hairy hack, unless we are talking about different things. I
> don't see a way to successfully resolve dependency problems this way.
> Fixing a broken rpmdb is not pretty work.
No, no, no. My example was "Suppose you try an update or install of a
list of packages that include something like pvm" where pvm has
basically nothing that depends on it but is useful to some people". If
yum looks at its list of files and finds packages missing, it could give
you a message like:
I cannot find the following packages:
pvm foo
and cannot install the following packages because of failed
dependencies:
bar [foo]
Do you want to proceed with the installation/update of all the OTHER
files and manage the update of these files by hand? (y/n)__
This lets somebody who doesn't need pvm or bar right away to proceed
with the update/install of everything else, and then if necessary graze
on the net for pvm and foo and come back and complete bar. I agree that
installing bar without foo is a Bad Idea.
Your biggest risk here is that it says something like:
I cannot find the following packages:
(important basic package)
and cannot install the following packages because of failed
dependencies:
(endless list of files)
Do you want to proceed with the installation/update of all the OTHER
files and manage the update of these files by hand? (y/n)__
and some idiot says yes and your dependency tree isn't precisely
accurate and the result breaks the system. This could be countered by
warning the user:
I cannot find the following packages:
pvm foo
and cannot install the following packages because of failed
dependencies:
bar [foo]
Do you want to proceed with the installation/update of all the OTHER
files and manage the update of these files by hand?
Note Well: This can be a risky thing to do, especially if there are a
lot of files in the lists above! Only say yes if you are CERTAIN that
omitting all the packages in these two lists will not damage the
integrity of your system!
You Have Been Warned!
(y/N)__
> Overall yum is effectively an interface which allows us to find the
> dependencies and pass a bunch of packages to "rpm -Uvh" -- it simply
> makes sure that all packages passed to rpm for upgrade/install have
> their dependencies resolved. If they weren't, rpm would bail saying "I
> need blah to install foo". Forcing things to install is not a good
> solution at all in my opinion.
>
> > 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.
>
> Bah! This is an admin tool. :) If people want hand-holding, there is
> up2date and rhn for just $60 a year. ;)
Admins don't need hand holding? That explains a lot...;-)
> > 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.
>
> I don't think we should compare fsck and yum. Fsck had everything needed
> to fix broken partitions already available in the code. Yum doesn't.
> Adding this interactivity for fsck was very simple, while for yum it
> would mean extra thousands lines of code.
>
> > 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.
>
> Again, if people want to upgrade their systems, they should really be
> using Anaconda -- it's got all that and a bag of [your favorite artery
> blockage snack]. It has nice graphical interfaces, both gtk and newt,
> with help screens and cute RH factoids for the times when you're just
> watching your packages install. The only major concern that I see is
> that you have to reboot your box to actually upgrade it, but maybe
> that's actually the right way to do it. :)
OK, I guess that you disagree. Although yum is interactive NOW in its
full update mode -- I had to answer a couple of questions about lists of
files before it would proceed with the 7.2->7.3 upgrade -- I was think
of this as basically more of the same.
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
