Yum problem

[Michael Schwendt]

On 26/10/2007, Claude Jones <cjones at levitjames.com> wrote:
>
> Don't run yum -y
> That just lets it go into robot mode - all confirmation queries
> in the normal yum process are answered with an auto 'y' key
> code. If you don't use the -y option, you get a confirmation
> dialog which you can minimally glance at and see if anything's
> amiss - it will tell you if it's going to remove something and
> give you the chance to say no.

Hyperbole.

The "(y/n)?" check during a pretty normal "yum -y update" comes very
early, even before downloading the packages and also prior to the
crucial transaction check. It is safe to use the normal "yum -y
update" mode, provided that yum doesn't suffer from a serious bug. Yum
is not so stupid to remove any packages that would break RPM package
dependencies during an update. Certainly it would not pull away its
own requirements, like rpm-python.

But you are advised to "yum -y update yum" after fresh installations
and prior to applying more than a dozen updates.

And remember, Fedora 7 is supposed to be the stable dist release. For
any update packages, which break something at _run-time_ (!) after
they got past the RPM transaction check, the packagers learn a lesson
when you report the breakage to them.

However, there are various yum plugins, yum-utils and package tree
cleanup functions, which may have bugs and which are not as tested.
So, be careful when trying to maintain your install-set with the aid
of automation.

There is /var/log/yum.log* as a place where yum logs its activity.
However, that log file is specific to yum [and some tools which use
yum as a back-end]. You don't find anything in it which you've done
with "rpm --erase --nodeps ..." and "rpm --force ...", respectively.
Those low-level operations are very dangerous, but too many people
recommend them even when they are completely inappropriate. Sometimes
users damage their RPM database unknowingly. Sometimes they run
unstable hardware that corrupts the database. E.g. RAM chips that
won't even pass memtest86.