Re: Yum problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 26/10/2007, Claude Jones <cjones@xxxxxxxxxxxxxx> 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.

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux