Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

YUM

The Yellow dog Updater, Modified (YUM) was written at the Duke University department of Physics and is currently being maintained by Seth Vidal and Michael Stenner, both of Duke University, as part of Duke University's Linux@DUKE project. YUM is a command line utility. There are several graphical frontends to yum. Among them pup, pirut, and yumex. Seth Vidal now works for Red Hat.

RHEL5 moved the entire stack of tools which install and update software to YUM. Now it became standard for RedHat and its derivatives. 

Yum is a rewrite of its predecessor tool, Yellowdog Updater (YUP). The latter was originally written and maintained by Dan Burcaw, Bryan Stillwell, Stephen Edie, and Troy Bengegerdes of Yellowdog Linux (an RPM-based Linux distribution that runs on Macintoshes ). 

Yum is written in Python. In RHEL 5 it replaced older up2date. Automatic software update can be done with either the yum-updatesd or the yum-updateonboot packages.

Yum's repository system is becoming the standard for RPM-based repositories. Besides the distributions that use Yum directly like Red Hat 5.1, SUSE Linux 10.1 adds support for Yum repositories in YaST. openSUSE Build Repository is also Yum-based. 

yum can do several things that yast cannot:

• install packages with the same name but for different architectures (which could be important for x86_64 users who sometimes can only install x86_32 packages).
• It can also check for the gpg keys.
• yum can handle mirror lists.

Yum (currently) consists of two tools; yum-arch, which is used to construct an (ftp or http) repository on a suitable server, and yum, the general-purpose client. Once a yum repository is prepared (a simple process detailed below) any client permitted to access the repository can install, update, or remove one or more rpm-based packages from the repository.

Yum's "intelligence" in performing updates is superior to most competitors (only smart comes close).

In addition, the yum client encapsulates various informational tools, and can list rpm's both installed and available for installation, extract and publish information from the rpm headers based on keywords or globs, find packages that provide particular files. Yum is therefore of a better tool them rpm for  users; with yum they can look over the list of available packages to see if there is anything "interesting", search for packages that contain a particular toot, etc.

Yum is designed to be a client-pull tool, permitting package management to be "centralized" to the extent required to ensure security and interoperability. No root privileges are required on yum clients -- yum requires at most anonymous access (restricted or unrestricted) from the clients to a repository server (often one that is maintained by a central -- and competent -- authority).

One of yum's most common uses for mass deployed linux clients (for example at the university) is to be run from a nightly cron script on each yum-maintained system to update every rpm package on the system safely to the latest versions available on the repository, including all security or operationally patched updates. This way using a common repository base an organization can achieve near complete consistency with respect to distribution, revision, and security. Security and other updates will typically appear on all net-connected clients no more than 24 hours after the an updated rpm is placed on the repository by its administrator who requires no root-level privileges on any of the clients. Consequently with yum a single administrator can maintain a rpm repository (set) for an entire organization.

An rpm consists of basically three parts: a header, a signature, and the (generally compressed) archive itself. The header contains a complete file list, a description of the package, a list of the features and libraries it provides, a list of tools it requires (from other packages) in order to function, what (known) other packages it conflicts with, and more. The basic rpm tool needs information in the header to permit a package to be installed (or uninstalled!) in such a way that:

• Installing the package breaks none of the already installed packages (recursively, as they may need packages of their own to be installed).
• All the packages that the package requires for correct operation are also (or already) installed along with the selected package, recursively.
• A later version of the package does not (accidentally) replace an earlier version of the package.

This process is generically known as "resolving package dependencies" and is one of the most difficult parts of package management. It is quite possible to want to install a packaged tool that requires two or three libraries and a tool. The libraries in turn may require other libraries, the tool other tools. By the time you're done, installing the package may require that you install six or eight other packages, none of which are permitted to conflict or break any of the packages that are already there or will remain behind.

If you have ever attempted to manage rpm's by hand, you know that tracking down all of the headers and dependencies and resolving all conflicts is not easy and that it actually becomes more difficult in time as a system manager updates this on one system, that on another, rebuilds a package here, installs something locally into /usr/local there. Eventually (sometimes out of sheer frustration) an rpm is --force installed, and thereafter the rpm database itself on the system itself is basically inconsistent and any rpm install is likely to fail and require --force-ing in turn. Entropy creeps into the network, and with it security risks and dysfunction.

Yet not updating packages is also a losing situation. If you leave a distribution based install untouched it remains clean. However, parts of it were likely broken at the time of install -- there are always bugs even in the most careful of major distributions. Some of those bugs are security bugs, and as crackers discover them and exploits are developed it rapidly becomes a case of "patch your system or lay out the welcome mat for vermin". This is a global problem with all operating systems; even Windows-based systems (notorious for their vulnerability to viruses and crackers) can be made reasonably secure if they are rigorously kept up to date. Finally, users come along and demand THIS package or THAT package which are crucial to their work -- but not in the original, clean, consistent installation.

Linux users need to have some sort of mechanism for updating the packages already installed on their system(s) to the latest, patched, secure, debugged versions and for adding more packages, including ones that may not have been in the distribution they relied upon for their original base install. The only questions are: what mechanism should they use and what will it cost them (in time, hassle, learning curve, and reliability as well as in money).

In a typical repository, there are several thousand packages, with a lot of headers. About 700 packages are actually installed on a typical linux system. However, the archive component of each package, which contains the actual binaries and libraries and documentation installed, is much larger -- the complete rpm is thus generally two to four orders of magnitude larger than the header. For example, the header for Open Office (a fairly large package) total about 100 kilobytes in size. The rpm itself, on the other hand, is about 30 megabytes in size. The header can be reliably delivered in a tiny fraction of a second over most networks; the rpm itself requires seconds to be delivered over 100Mbit/sec LAN.  Early automated update tools either required a locally mounted repository directory in order to be able to access all of the headers quickly (local disk access even from a relatively slow CD-ROM drive, being fast enough to deliver the rpm's in a timely way so that their headers could be extracted and parsed) or required that each linked rpm be sent in its entirety over a network to an updating client from the repository just so it could read the header. One was locally fast but required a large commitment of local disk resources (in addition to creating a new problem, that of keeping all the local copies of a master repository synchronized). The other was very slow. Both were also network resource intensive.

This is the fundamental problem that yum solves for you. Yum splits off the headers on the repository side (which is the job of its only repository-side tool, yum-arch). The headers themselves are thus available to be downloaded separately, and quickly, to the yum client, where they are typically cached semi-permanently in a small footprint in /var/cache/yum/serverid (recall that serverid is a label for a single repository that might be mirrored on several servers and available on a fallback basis from several URL's). Yum clients also cache (space permitting or according to the requirements and invocation schema selected by the system's administrator) rpm's when they are downloaded for an actual install or update, giving a yum client the best of both the options above -- a local disk image of (just the relevant part of) the repository that is automatically and transparently managed and rapid access to just the headers.

An actual download of all the headers associated with packages found on your system occurs the first time a yum client is invoked and thereafter it adds to or updates the cached headers (and downloads and caches the required rpm's) only if the repository has more recent versions or if the user has deliberately invoke yum's "clean" command to empty all its caches. All of yum's dependency resolution then proceeds from these cached header files, and if for any reason the install or update requires an rpm already in the cache to be reinstalled, it is immediately available.

By NFS exporting and mounting (rw,no_root_squash) /var/cache/yum to all the LAN clients, you can speed up operations with remote repositories as they are available to all the local hosts over a 100Mbit/sec NFS mount. This saves tremendously on bandwidth and YUM server load. Best of all, there "is no setup".

However, it is probably better in many cases to use rsync or other tools to provide a local mirror of the repository in question and use yum's fallback capability to accomplish the same thing. This gives one a much better capability of standing alone should update access go away on the "server" of the yum cache NFS exported across a LAN.

With the header information (only) handy on high-speed local media, the standard tools used to maintain rpm's are invoked by yum and can quickly proceed to resolve all dependencies, determine if it is safe to proceed, what additional packages need to be installed, and so forth. Note well that yum is designed (by a highly experienced systems administrator, Seth Vidal, with the help of all the other highly experienced systems administrators on the yum list) to be safe. It will generally not proceed if it encounters a dependency loop, a package conflict, or a revision number conflict.

If yum finds that everything is good and the package can be safely installed, removed, or updated, it can either be invoked in such a way that it does so automatically with no further prompts so it can run automagically from cron, or (the general default when invoked from a command line) it can issue a user a single prompt indicating what it is about to do and requesting permission to proceed. If it finds that the requested action is in fact not safe, it will exit with as informative an error message as it can generate, permitting the system's administrator to attempt to resolve the situation by hand before proceeding (which may, for example, involve removing certain conflicting packages from the client system or fixing the repository itself).

From the overview given above, it should be apparent that yum is potentially a powerful tool indeed, using a single clever idea (the splitting off of the rpm headers) to achieve a singular degree of efficiency. One can immediately imagine all sorts of ways to exploit the information now so readily available to a client and wrap them all up in a single interface to eliminate the incredibly arcane and complex commands otherwise required to learn anything about the installed package base on a system and what is still available. The yum developers have been doing just that on the yum list - dreaming up features and literally overnight implementing the most attractive ones in new code. At this point yum is very nearly the last thing you'll ever need to manage packages on any rpm based system once it has gotten past its original, distribution vendor based, install.

Indeed, it is now so powerful that it risks losing some of its appealing simplicity. This HOWTO is intended to document yum's capabilities so even a novice can learn to use it client-side effectively in a very short time, and so that LAN administrators can have guidance in the necessarily more complex tasks associated with building and maintaining the repositories from which the yum clients retrieve headers and rpm's.

Yum's development is far from over. Volunteers are working on a GUI (to encapsulate many of yum's features for tty-averse users). Some of yum's functionality may be split off so that instead of a single client command there are two, or perhaps three (each with a simpler set of subcommand options and a clear differentiation of functionality). The idea of making yum's configuration file XML (to facilitate GUI maintenance and extensibility) is being kicked around. And of course, new features are constantly being requested and discussed and implemented or rejected. Individuals with dreams of their own (and some mad python or other programming skills:-) are invited to join the yum list and participate in the grand process of open source development.

rpm doesn't permit one to tell it to "install package X and anything else that it needs, after YOU figure out what that might be". Yum, of course, does.

Even yum, though, can't "fix" a dependency loop, or cope with all the arcane revision numbering schemes or dependency specifications that appear in all the rpm's one might find and rebuild or develop locally for inclusion in a central repository. When one is encountered, a Real Human has to apply a considerable amount of systems expertise to resolve the problem. This suggests that building rpm's from sources in such a way that they "play nice" in a distribution repository, while a critical component of said repository, is not a trivial process. So much so that many rpm developers simply do not succeed.

Also, yum achieves its greatest degree of scalability and efficiency if only rpm-based installation is permitted on all the systems using yum to keep up to date.

Consequently, repository maintainers must willy-nilly become rpm builders to at least some extent. If SuSE releases a lovely new tool in source rpm form that isn't in your current Red Hat based repository, of course you would like to rebuild it and add it. If your University has a site license for e.g. Mathematica and you would like to install it via the (properly secured and license controlling) repository you will need to turn it into an rpm. If nothing else, you'll need to repackage yum itself for client installations so that its configuration files point to your repositories and not the default repositories provided in the installation rpm's /etc/yum.conf.

Cheat sheet

Most options come in two flavors: a long option and a short option. The long option features two hyphens and the full option name, the short one hyphen and - in most cases - the first character of the full option. Of course you only have to provide one option form (i.e. either rpm --install [name] or rpm -i [name]).

Installation/Removal

• yum install foo - install package foo
• yum remove foo - remove package foo with dependencies
• yum update foo - update only package foo 
• yum update - update the whole system

Queries

• yum search whatever - search for this string
• yum info foo - give the infos about this package
• yum provides foo_library - which package has this library?

Repo files

On invocation yum first checks its configuration file /etc/yum.conf which store all information about the repositories in /etc/yum.repos.d/.

The files in this directory should have an extension repo and format like this:

[base]
name=SUSE LINUX 10.0 - Base
baseurl=ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse
enabled=1
gpgcheck=1
gpgkey=ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/pubring.gpg

The first option shows the name - this must be unique because yum uses it to identify the repository and the cached data about it.

The second option, the name field, is for the user to know what he has configured.

baseurl gives the server and the directory where yum can find the packages.

You can use mirrorlists instead.  The url to the mirrorlist is part of the field mirrorlist - due to the fact the no server provides them, we have to make our own. Some mirrorlists:

• the SUSE LINUX 10.0 base files
• some german mirrors for the base files
• the java files
• some german mirrors for the java files
• packman files
• packman mirrors, at this moment only the server in Bremen
• the GM files (proprietary stuff)
• some mirrors for this stuff
• the update files
• some mirrors for the update servers

Creation of private Yum repositories

There are three steps to creating a yum repository:

• copy RPMs to the selected directory
• index the RPMs.
• Create a repo file for the new yum repository in  /etc/yum.repos.d/

If you have a special repository which you really like, but which does not support yum, you can use a trick: make a local mirror of the files via rsync or similar utility and then create a local YUM repository. To convert directory with RPMs into YUM repository you need to run a special utility createrepo

yum install createrepo

To create a repository you need to run it with a single parameter, the root of  RPM directory tree (you can use subdirectories for various groups of RPMs):

createrepo /var/cache/myrepo

After running the utility you can notice that in the directory /var/cache/yum/myrepo there is a new directory called repodata with data describing RPMs in it. 

The last step is to create the file with extension repo, for example, my.repo  in /etc/yum.repos.d/:

[myrepo]
name=my cool repo
baseur=file:///var/cache/myrepo
enabled=1

At this point you should be able to install RPM from local repository using yum. You can  use wget and cron-jobs for synchronizing of the local repository.  After each synchronization you need to update the repodata directory using createrepo

Serve up yum repository

Once the repository is constructed, it must be made available by http, ftp, or rsync. If the repository is made in the root document tree of your web server, e.g., /var/www/html/, the following entry should be added to /etc/httpd/conf/httpd.conf:

<Directory /var/www/>
Options +Indexes
</Directory>

in order to allow the directories to be listed. Reload the httpd configuration file with

# /sbin/service httpd reload

References

Yum: Yellow dog Updater, Modified Homepage
Charles Curley's Yum Repository Notes
Yum (Yellow dog Updater, Modified) HOWTO
YUM: Yellowdog Updater, Modified

Old News ;-)

Using apt in an RPM world Field Commander Wieers

Okay. Now my issue against apt. When you look for an libraries which is needed in an package you can use in RHEL/CentOS environments

up2date --whatprovides=lib.so.5.2

or

yum provides lib.so.5.2

This shows which packages provides that specific file. apt does not have this feature as far as I know.

Yum & Repositories

I noticed this issue with both CentOS 4 and 5 - Yum will often choose bad mirrors from the mirrorlist file - for example, choosing overseas servers, when an official NZ server exists. And in some cases, the servers it has chosen are horribly slow.

You will probably find that you get better download speeds by editing /etc/yum.repos.d/CentOS-Base.repo and commenting out the mirrorlist lines and setting the baseurl line to point to your preferred local mirror.



Yum-updatesd
CentOS 5 has a new daemon called yum-updatesd, which replaces the old cron job yum update scripts. This script will check frequently for updates, and can be configured to download and/or install them.

However, this daemon is bad for a server, since it doesn't run at a fixed time - I really don't want my server downloading and updating software during the busiest time of day thank-you-very-much!

So, it's bad for a server. Let's disable it with:
 

service yum-updatesd stop
chkconfig --level 2345 yum-updatesd off

Plus I don't like the idea of having a full blown daemon where a simple cronjob will do the trick perfectly fine - seems like overkill. (although it appears yum-updatesd has some useful features like dbus integration for desktop users)

So, I replace it with my favorite cronjob script approach, by running the following (as root of course):
 

cat << "EOF" > /etc/cron.daily/yumupdate
 #!/bin/sh
 # install any yum updates
/usr/bin/yum -R 10 -e 0 -d 1 -y update yum > /var/log/yum.cron.log 2>&1
/usr/bin/yum -R 120 -e 0 -d 1 -y update  >> /var/log/yum.cron.log 2>&1
if [ -s /var/log/yum.cron.log ]; then
        /bin/cat /var/log/yum.cron.log | mail root -s "Yum update information" 2>&1
fi
EOF

and if you want to clear up the package cache every week:
 

cat << "EOF" > /etc/cron.weekly/yumclean
 #!/bin/sh
 # remove downloaded packages
/usr/bin/yum -e 0 -d 0 clean packages
EOF

(please excuse the leading space infront of the comments ( #) - it is to work around a limitation in my site, which I will fix shortly. Just copy the lines into a text editor and remove the space, before pasting into the terminal)

This will install 2 scripts that get run around 4:00am (as set in /etc/crontab) which will check for updates and download and install any automatically. If there were any updates, it will send out an email, if there were none, it doesn't send anything.

(of course, you need sendmail/whatever_fucking_email_server_you_like configured correctly to get the alerts!)

You can change yum to just download and not install the updates (just RTFM), but I've never had a update break anything - update compatibility and quality is always very high - so I use automatic updates.

CentOS 4 had something very similar to this, with the addition of a bootscript to turn the cronjobs on and off.

* Please check out the update at the bottom of this page for futher information on this. UPDATE - 1st May 2007

A reader has informed me that the old RHEL 4 style cronjobs can be found in a package called 'yum-cron'. Just like in RHEL 4, it installs a service called "yum" which you can enable with:
 

chkconfig --level 2345 yum on
service yum start

However, I will point out a small difference with the Redhat cron script vs. my cron script - the Redhat one will send the list of updates as an email from cron (as cron simply emails the output the script produces). My version allows you to change the subject, and the destination email address. This may/may not be useful to you.

The same reader also points out that there is another package in the CentOS extras repository called 'yum-updateonboot', which installs bootscripts which update your system when you boot it, and will then reboot if there are any kernel updates needed.

You should be able to (I haven't tried myself) enable it with:
 

chkconfig --level 2345 yum-updateonboot on

Upgrading Red Hat Linux/Fedora Core with yum

Before performing an upgrade with yum, please read the YumUpgradeFaq Wiki.

The basic steps for upgrading a system to the latest Fedora Core release using yum:

1. Install the fedora-release package from the new release
2. Run yum upgrade
3. Reboot

Upgrading to Fedora Core 4

The following steps were used to update a Fedora Core 3 system to Fedora Core 4 using yum.

1. Update yum to the latest Fedora Core 3 version.
# yum -y update yum

2. Download and install the Fedora Core 4 version of fedora-release from one of the Fedora Core mirrors.

Example:
# rpm -Uvh http://download.fedora.redhat.com/pub/fedora/linux/core/4/i386/os/Fedora/RPMS/fedora-release-4-2.noarch.rpm

3. Disable third-party yum repositories, if applicable.

In my configuration, I had the Dag, FreshRPMs, and Dries third-party yum repositories enabled. As of 2005/06/15, only the Dries repository caused an error message (i.e. it had not been updated with Fedora Core 4 packages or it did not have a Fedora Core 4 directory structure) so I will only disable that repository.

# echo "enabled=0" >> /etc/yum.repos.d/dries.repo

4. When upgrading to Fedora Core 4, the kernel must be upgraded before the rest of the packages.
# yum -y update kernel

Otherwise, you may receive the following error message:

--> Running transaction check
--> Processing Dependency: kernel-utils for package: kernel
--> Finished Dependency Resolution
Error: Missing Dependency: kernel-utils is needed by package kernel

5. Disable SELinux, if applicable, and reboot the system to begin using the Fedora Core 4 kernel. I ran into significant problems after this reboot when SELinux was enabled.

To disable SELinux:

# vi /etc/sysconfig/selinux

Change:
SELINUX=enforcing
-- or --
SELINUX=permissive

To:
SELINUX=disabled

# reboot

7. Remove the Fedora Core 3 kernel(s) to prevent the aforementioned kernel-utils package dependency error.
# yum remove kernel-2.6.\*FC3\*
# yum remove kernel-smp\*FC3\* (if you have one or more FC3 SMP kernels installed)

8. Continue the upgrade to Fedora Core 4.
# yum -y upgrade

Note: if you receive the following error, import the RPM-GPG-KEY.

warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID db42a60e
public key not available for caching-nameserver-7.3-3.noarch.rpm

# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY

9. Reboot the system to begin using Fedora Core 4.

10. If applicable, re-enable SELinux by undoing the changes above, and reboot the system to use SELinux.

User-contributed notes on Upgrading to Fedora Core 4

On 2005/07/16, Jay Thorne wrote:

Before you upgrade the kernel, you need to upgrade mkinitrd, otherwise
the initrd that the kernel install process makes is in the old format
and the new kernel will not boot; it dies with a oops.

# yum -y upgrade mkinitrd

Otherwise, this procedure works well. Good work.

Also, in the x86_64 case, you need to specifically upgrade
libselinux.i386 and libselinux.x86_64 before the kernel upgrade, or the
upgrade will fail with a conflict.

# yum -y upgrade libselinux.i386 libselinux.x86_64

Thanks for Wim Cos for writing on 2005/06/16 and providing the steps to update yum to the latest FC3 version and for the steps to remove FC3 SMP kernels, if applicable.

Build Service-User - openSUSE

For SUSE Linux 9.3, 10.0, 10.1 and Factory, you can also use smart', zypper, yum, or apt to install and update packages from the Build Service. The latest smart and yum packages can be found at http://download.opensuse.org/repositories/smart/

Zypper

With openSUSE 10.2, you can also use the command line tool named zypper to add repositories:

zypper sa -r <URL_to_your_repo_file>

For example:

zypper sa -r http://download.opensuse.org/repositories/openSUSE:/Tools/SUSE_Linux_Factory/openSUSE:Tools.repo

For more information, use

zypper help

 

Smart

smart channel --add http://download.opensuse.org/repositories/<projectname>/<directory>/<project>.repo

To install a package you need to call

 smart update
 smart install <package>
 smart upgrade    # Performs an upgrade of all installed packages using the new repositories.

yum

YUM can use the repositories after the generated .repo file got copied into the /etc/yum.repos.d/ directory. Afterwards you can use yum commandline tools or GUI tools like kyum.

APT

APT isn't very well supported on openSUSE, so we recommend that you use one of the other above methods instead. This paragraph is a translation of an updated article for SuSE Linux 10.1 Apt v SUSE LINUX 10.1 from the czech SuSE portal which deals with the installation and usage of APT (Advanced Package Tool) in SUSE.

First we need apt and apt-libs. Both packages can be found on the DVD. The graphical front-end for Apt - Synaptic - is missing for an unknown reason, so we must be content with the command line version.

To install the above mentioned packages successfully we need to download and install the package install-apt4suse.rpm. The easiest installation is to launch mc as root, find and open the downloaded package by Enter and start the script INSTALL.

In a further step we launch:

 install-apt4suse --update-srclist

which updates the current list of mirrors. The result can be checked in /etc/apt/sources.list. The following table shows the commands which can be used with APT:

apt-get update	Creates a list of available packets
apt-get upgrade	Updates pre-installed packets by newer versions
apt-get -s upgrade	Shows more details about what is to be updated
apt-get -s install "packet name"	Shows more details about what is to be installed
apt-get install "packet name"	Installs a packet
apt-get reinstall "packet name"	Re-installs a packet
apt-get remove "packet name"	Removes a packet
apt-get clean	Cleanup of the buffered setups

In case of errors with GPG during the installation process open the file /etc/apt/apt.conf.d/gpg-checker.conf and change the entry

 GPG::Check true;

to

 GPG::Check false;

The usage of APT is faster and more transparent to end users compared to YaST and the new ZEN installer.

See also The Advanced Package Tool for SUSE for more information.

HelpUpdate suse - SUSE Wiki

Some options associated with the yum command:

• yum - display brief help (is the package installed?)
• yum check-update - displays any updates the current system needs
• yum update - check for updates and apply them interactively
• yum update <package> - check for updates and upgrade a specified package
• yum info - similar output to a rpm -qai
• yum info <package> - information about a specific package
• yum list - lists all available packages
• yum list <package> - list individual package(s)
• yum list installed - list all installed packages
• yum list available - list all packages not installed
• yum list update - list all packages that need to be upgraded
• yum clean - delete any rpms in the yum cache and remove any unneeded headers
• yum install <package> - install the package (or yum –y install <package>)
• yum remove <package> - delete the package
• yum search <string> - searches for packages containing the string in their name or header info
• RUN this command at TERMINAL --> yum check-update [ENTER]

Index of -repo-hardware

yum repository for suse 10.1 - LinuxQuestions.org

Go here:
http://linux01.gwdg.de/~pbleser/rpm-...=/System/smart

Install smart. It is better then Yum and it can handle multiple repostory types. Yast, Yum, Apt-get, Red Carpet, CD/DVD, plain directory are all handled well by Smart.

[Mar 23, 2007] Using YUM in RHEL5 for RPM systems

There is more to Red Hat Enterprise Linux 5 (RHEL5) than Xen. I, for one, think people will develop a real taste for YUM (Yellow dog Updater Modified), an automatic update and package installer/remover for RPM systems.

YUM has already been used in the last few Fedora Core releases, but RHEL4 uses the up2date package manager. RHEL5 will use YUM 3.0. Up2date is used as a wrapper around YUM in RHEL5. Third-party code repositories, prepared directories or websites that contain software packages and index files, will also make use of the Anaconda-YUM combination.

... ... ...

Using YUM makes it much easier to maintain groups of machines without having to manually update each one using RPM. Some of its features include:

• Multiple repositories
• Simple config file
• Correct dependency calculation
• Fast operation
• RPM-consistent behavior
• comps.xml group support, including multiple repository groups
• Simple interface

RHEL5 moves the entire stack of tools which install and update software to YUM. This includes everything from the initial install (through Anaconda) to host-based software management tools, like system-config-packages, to even the updating of your system via Red Hat Network (RHN). New functionality will include the ability to use a YUM repository to supplement the packages provided with your in-house software, as well as plugins to provide additional behavior tweaks.

YUM automatically locates and obtains the correct RPM packages from repositories. It frees you from having to manually find and install new applications or updates. You can use one single command to update all system software, or search for new software by specifying criteria.