Softpanorama (slightly skeptical) Open Source Software Educational Society

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

RPM Usage Tutorial

The most common format in which software packages are made available for SUSE Linux is a package format called RPM, which originally stood for "RedHat Package Manager".  The RPM system was developed in 1995 to manage applications in Red Hat Linux 2.0 and is derivative of the Solaris packaging system.  It was the successor to a collection of Perl scripts that functioned as the earliest Linux packaging tools. Rewritten in the C language in 1996, it quickly became the de facto standard for managing application installations for several Linux distributions, including SUSE. Later RPM was renamed "RPM Package Manager". The name RPM refers to two things: a software package format, and the utility for maintenance of  software packaged in this format.

RPM is not the only package format around; another popular format is the one used by Debian Linux (usually called .deb packages), which has many supporters and is used in Debian and Ubuntu distributions. There are other formats used to distribute software—in particular, .tar archives ("tarballs"), which are more often used to distribute source code. Other versions of Unix have their own packages formats, such as the pkgadd format used by Solaris.

The basic idea behind RPM is to have an "enhanced archive" of a compiled binary files along with the necessary configuration files that can be unpacked on the system with "one click" in working package installation and later upgraded to a new version or deinstalled without remembering all the places where the fie went.  An RPM database of all available applications is installed on your computer (in /var/lib/rpm) and this database is accessible by various tools including YaST. It helps to determine exactly what is on your system, what might be new and updated, and what files each package provides that another package might need to run properly.

Created by Red Hat, RPM is probably the most popular Unix/Linux package format. Most popular are binary packages. Good place to search for RPM packages is  rpmfind.net, one of the world's largest archives of user and vendor-donated RPM packages.

An easy way to install RPMs along with associated dependencies is to use yum (Yellow dog Updater, Modified) or apt for RPM. Of the two products, I would recommend using yum, as it has a smaller code base than apt for RPM, it is written in python (similar to Red Hat's anaconda installer), and it makes upgrading to new Red Hat releases relatively easy (apt for RPM has a dist-upgrade feature, but I have never tried it).

Red Hat Linux's up2date command will also install Red Hat's RPMs along with dependencies. However, up2date is not as flexible in incorporating third-party RPMs, such as those at freshrpms.net.

When source code is compiled, the way that the binary package is produced is dependent on a number of things. A major factor is the type of processor the machine is using. Examples of processor types include: Intel/x86, used in PCs and Sun Sparc. Also important are the system libraries that should be used. "Sparc" in the filename or directory name often indicates that the package has been made specifically for a machine with a Sparc processor and will not work with anything else. "i386" means normal PC clone workstations -- Intels, AMDs, Cyrixs and the like. "Noarch" tends to be more for scripts and documentation packages which could be used on any of these systems. Other names that may crop up often include "m68k," "alpha," and "ppc." The point is that you will need to be aware of these distinctions when downloading your packages.

When installing a package, the rpm update a central database that is installed on your system (RPM-based integrity checking for additional details). Presence of database helps to ensure that the same package is not installed twice, or that by installing this package you'd be "downgrading" to lower version.

One of the more complex but highly useful commands allows you to install packages with dependencies  (note option -- aid) via FTP or HTTP. If you are connected to the net and want to install a new package foobar-1.0-1.i386.rpm, all you need to do is specify the file with a valid URL, like so:

rpm -ivh --aid ftp://ftp.redhat.com/pub/redhat/rh-2.0-beta/RPMS/foobar-1.0-1.i386.rpm

faqcentos [Sample - DokuWiki]

rpm -i --aid package

Perhaps the –aid switch is a redhat only thing ?

using centos or other new redhat/linux distributions rpm has the option aid (–aid ) for automatically install dependents I assume. This seems great that any package that wont install because of failed dependencies can be installed as the rpm program will find the needed suggested packages.

I needed this when after install centos we wanted to add X windows and Gnome but the number of dependencies was a bit daunting. But using the –aid switch and pointing it at a location containing all the rpms shipped with the system meant that once we had almost any X package installed we should have a running GUI system.

But it expects it to be in an “unusual” location. I suspect it also looks in the current directory. To change the location it will install the packages from your need to change this file

/etc/rpm/macros.solve

The most typical command for the installation of a package is :

#  rpm -iv http-server-2.0.4-9.i386.rpm
error: failed dependencies: http is needed by http-server-2.0.4-9
libhttp.so.2 is needed by http-server-2.0.4-9

Cheat sheet

The most frequently used rpm options (packagename below is just mane, it does not need to contain version or extension (.rpm)):

• Show all packages and or files installed (you can use grep to narrow the search instead of rpm facolities):

  • rpm -qa  | sort

  • rpm -qa | grep mysql    # do I have mysql installed ?

  • rpm -qal  # list all installed files.
     

• Install a package rpm -i packagename

  • rpm -ivh --aid #  option --aid installs dependencies

  • rpm -ivh --force --nodeps ***.rpm # force installation of the package disregarding dependencies.
     

• List content of the package. Attention: the name of the package should a a single name (no dots).

  rpm -ql packagename

  • rpm -q foo # prints packagename, version, release number

  • rpm -qipl foo  # list package foo information

  • To list the content of the package you can combine some of the short options (rpm -qpi [name])
     

• What RPM a file belongs to (you need to provide path and name not just name): 
  
    rpm -q --whatprovides /usr/bin/w
   

• Upgrade the package. Notice it's a capital U. Upgrades an installed program with a newer package.

  • rpm -U   packagename

  • rpm -Uvh http: <server>
     

• Uninstall the package

  • rpm -e packagename .  Sometimes you need to delete dependencies first.

  • rpm -ev                     (removing ..)

One of the more complex but highly useful commands allows you to install packages via FTP or HTTP. If you are connected to the net and want to install a new package, all you need to do is specify the file with a valid URL, like so:

rpm -ivh --aid ftp://ftp.redhat.com/pub/redhat/rh-2.0-beta/RPMS/foobar-1.0-1.i386.rpm   

Basic Commands

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]).

• rpm --install (-i) [name] installs a package.
• rpm --erase (-e) [name] erases it.
• rpm --upgrade (-U ,notice it's a capital U!) [packagename] upgrades an installed program with a newer package.
• rpm --query (-q) [name] queries for packagename and version of an installed program
• rpm --query --package (-qp) [name] does the same on a package which isn't installed
• rpm --query --package --info (-qpi) [name] tells you what the package is about, who packaged it etc.
• rpm --verify (-K ,for some reason)[name] will tell you if all files of the packages are still (or at all) installed.

Example:

 rpm -qa | grep lesstif (do I have LessTif installed ?)
  FuzzyVibe:~# rpm -qa | grep lesstif
  lesstif-0.80-2

  Yes, oh well, what is it ? ;-)
  rpm -qi lesstif

  What files does the package contain ?
  rpm -qs lesstif

  Oh, where's the LessTif-FAQ, if any ?
  rpm -qs lesstif | grep -i "faq"

Notes: Those pages are written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected. This is a Spartan WHYFF (We Help You For Free) site. It cannot replace the best teachers and the best books. The site contain some obsolete pages as it develops like a living tree... Some links on older pages are broken. Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link. Search Amazon by keywords:     Open directory Research Index

Old News ;-)

[Apr 3, 2008] rpmrebuild 2.2.1-1 by Gerbier Eric

About: rpmrebuild is a tool to build an RPM file from a package that has already been installed. It can be used to easily build modified packages, and works on any Linux distribution that uses RPM.

Changes: A bug where the --pug-from-fs option did not keep the UID/GID was fixed. Two new plugins were added to help users understand and develop their own plugins. A UTF-8 French localization was included.

[Oct 29, 2007] freshmeat.net Project details for AutoUpdate

AutoUpdate is a Perl script which performs a task similar to Red Hat's up2date or autorpm. It can be used to automatically download and upgrade RPMs from different HTTP(S) or (S)FTP sites, while also handling dependencies. Moreover, it can also be used to keep a server with a customized (Red Hat) distribution plus all clients up to date.

Release focus: Minor bugfixes

[Apr 29, 2007] freshmeat.net Project details for rpm orphan

rpmorphan finds "orphaned" RPM packages on your system. It determines which packages have no other packages depending on their installation, and shows you a list of these packages. It is a clone of the deborphan program from Debian, but for RPM packages.

Release focus: Major feature enhancements

Changes:
A bug in the Tk interface was fixed. A simulation mode was added. Severals counters were added to the GUI. The GUI can now re-analyze dependencies after package removal. Virtual package treatment was improved, and the tool now checks how many packages provide the virtual.

Author:
Gerbier Eric [contact developer]

[Mar 30, 2006] BigAdmin Feature Tech Tip Short Overview of RPMs in Linux by Serge Burlyga

March 2006 Abstract: This introduction to RPMs covers different types of queries as well as tips on how to obtain information on RPMs and list their contents.

I. The Simplest Query

The query options are accessed by using the -q or --query option to the rpm command. By default the query is applied to one or more installed package listed by name at the end of the query, like this:

rpm -q <packagename> [<packagename>...]

The -q option with no additional options returns the canonical name-version-release string for a package. For example:

$ rpm -q filesystem 

filesystem-2.2.1-3

II. Querying Package Files

To apply the query to a package file instead of a currently installed package, use the -p or --package option. For example:

$ rpm -qp sun-icu-2.1-6.i386.rpm
sun-icu-2.1-6

You may list more than one package file, or use shell globbing.

Note that this information was retrieved from the contents of the RPM file itself, not from the file name. Renaming the package file does not affect these values. For example:

$ mv sun-icu-2.1-6.i386.rpm charmander.sdklfj
$ rpm -qp charmander.sdklfj
sun-icu-2.1-6

All query commands may be applied to a package file simply by adding the -p option to the command.

III. Querying All Installed Packages

To apply the query to all installed package, use the -a option. Do not specify any individual RPMs to query. Without any additional options, this lists all packages installed on the system in canonical name-version-release format. For example:

$ rpm -qa | head -10
dietlibc-0.21-7
kon2-fonts-0.3.9b-18.1
man-pages-fr-0.9.7-7
kudzu-devel-1.1.21-1
basesystem-8.0-2
bogl-0.1.9-27
compat-slang-1.4.5-5
diffstat-1.31-2
elfutils-0.89-1
glib-1.2.10-11.1
[...and so forth]

All query commands may be applied to all installed packages simply by adding the -a option to the command. Be careful, as this can result in a lot of information.

IV. Useful Queries

The full list of query options is described in the QUERY OPTIONS section of the rpm man page. Here are the most useful:

General Information

The -i or --info flag returns general descriptive information about the RPM. This information includes the build date and build host name. For example:

$ rpm -qpi sun-icu-2.1-6.i386.rpm
Name : sun-icu
Relocations: (not relocateable)
Version : 2.1
Vendor: Sun Microsystems, Inc.
Release : 6
Build Date: Mon 23 Feb 2004 12:07:17 PM PST
Install Date: (not installed)
Build Host: zzz-build.Sun.COM
Group : Operation System Environment
Source RPM: sun-icu-2.1-6.src.rpm
Size : 12387614
License: ICU License -ICU 1.8.1 and later and Sun Microsystems Binary
Code License (BCL)
Signature : (none)
Packager : Sun Microsystems, Inc.
URL : http://www.sun.com/
Summary : International Components for Unicode 2.1 with Sun enhancements
Description : The sun-icu package contains ICU 2.1 version of
internationalization
libraries and header files for C and C++ programming languages with
additional Sun-specific enhancements.

Listing All Files Contained in the RPM

Use the -l or --list option to list all files in a package. For example:

$ rpm -qpl sun-icu-2.1-6.i386.rpm | head -10
/opt/sun/private/include/layout/ArabicLayoutEngine.h
/opt/sun/private/include/layout/GXLayoutEngine.h
/opt/sun/private/include/layout/IndicLayoutEngine.h
/opt/sun/private/include/layout/LEFontInstance.h
/opt/sun/private/include/layout/LEGlyphFilter.h
/opt/sun/private/include/layout/LEScripts.h
/opt/sun/private/include/layout/LESwaps.h
/opt/sun/private/include/layout/LETypes.h
/opt/sun/private/include/layout/LayoutEngine.h
/opt/sun/private/include/layout/OpenTypeLayoutEngine.h
[...and so forth]
 

V. Querying Individual Package Fields

The --queryformat or --qf option allows you to query rpm for one or more fields, formatting the results however you see fit. This is very useful in scripting situations. This command may be applied to one or more installed packages, to all installed packages, or to one or more RPM package files.

$ rpm -q --qf
'%{name}\t%{version}-%{release}\t%{buildhost}\t%{buildtime}\n' mozilla
mozilla-nss mozilla-nspr
mozilla 1.4-3.0.18 porky.devel.redhat.com 1064264992
mozilla-nss 1.4-3.0.18 porky.devel.redhat.com 1064264992
mozilla-nspr 1.4-3.0.18 porky.devel.redhat.com 1064264992

See the man page for additional options which allow you to control the format of the individual fields.

For a list of all fields you may query, run rpm --querytags.

VI. Removing RPMs

Use the following command to remove RPMs:

$ rpm -e {name}

[Jun 13, 2005] Top ten problems in RPM

When we added RPM support to APT for Conectiva Linux, a few years ago, we found it many times slower than APT in Debian under similar circumstances. It is clear for us now that this is caused mainly by the Berkeley database backend used in RPM, the non-uniform handling of file dependencies and the large number of hidden dependencies automatically added by RPM.

APT is an excellent tool, and it would be a highly un-scientific procedure just to dismiss it without careful evaluation. When proposing a solution, we must make sure to do proper research and use what we learned as a start point for a better design. Improving APT rather than creating a yet-another-update-tool was strongly advocated by Arnaldo to fight the NMH syndrome that is known to result in the spawning of a myriad of incompatible, incomplete or ill-designed clones of many software products created by or for a specific Linux distribution. A careful study of existing tools is essential to build better alternatives, and it took Conectiva four years of APT development and usage to decide for a new design.

The same applies to RPM. Anyone willing to come with a better alternative should make sure it can fix the maximum possible number of problems in existing implementations (including the issues listed below), and prefereably outdo RPM in every single field, which is not an easy task. The good points, such as the single specfile, pristine source, multi-patch and source package concepts should of course be kept. I understand that RPM is not new and many of its current problems couldn’t be predicted at the time it was designed, or even at the code overhauls it suffered along its evolutionary path. However, there’s no excuse for any next-generation replacement to ignore these issues or not solve them by just not understanding the real nature of the problem.

So, without further ado, here are the ten main problems I’d like to see fixed in an eventual RPM successor (or in a sanitized RPM reimplementation), in no particular order:

1. Berkeley database backend. Dpkg does a much faster and at least equally reliable job with plaintext files, which don’t get corrupt as often, don’t need periodic reconstruction and are human-readable. The SQL database backend is a huge step in the wrong direction.
2. Installation of new package before removal of the previous version. This adds unnecessary complexity and leads to a non-intuitive sequence in execution of pre- and post- install/uninstall scriptlets, and can create problems only solvable using triggers. Triggers shouldn’t exist, they only solve problems caused by design problems and policy flaws.
3. Network awareness features. It increases size and complexity of the binary, and tries to perform a task that should belong to an external utility such as Apt-get or Smart. Recent versions try to contact PGP keyservers and block execution when it fails.
4. Obtuse macro expansion and commentary handling in specfiles. Macros expand inside comments, and line breaks cause unexpected behavior.
5. Absence of logical OR in requirements forces the developer to always regenerate all alternative packages to provide virtual packages.
6. Incomplete timestamp format in specfile changelogs. Standard date(1) format or other providing time of change is needed.
7. File dependencies are treated in a special way and are not regular virtual packages (a better design would make packages relate only to other packages, real or virtual). They increase complexity of dependency resolution and promote sloppy pratices in software packaging.
8. Problematic handling of simple situations such as replacing directories with symlinks. Bad habit of stating all mounted filesystems prior to installation (at least in earlier versions).
9. Non-intuitive (or plain broken) algorithm to compare package versions (example: 1a > 1B) . Epoch zero is considered newer than no epoch at all.
10. No provisions for interactive configuration scripts or human inspection/approval of new configuration files, and no concept of post-transaction configuration.

Can all these be solved in a single software product? Dpkg is not the answer, it also has its share of problems (no source package, no simple multi-patch or multi-source handling, package creation and metadata maintenance not as straighforward as RPM). Combining the best features of both package managers — the RPM front-end with the Dpkg back-end — would make life easier for both users and maintainers. Reimplementing a subset of the RPM specification in such a way that it complies with the LSB requirements for a package manager and is backwards-compatible with most (but not all) existing packages could be a solution. Any takers?

This entry was posted on Monday, June 13th, 2005 at 10:37 pm and is filed under Software, Nuisances, Linux, Standards. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

6 Responses to “Top ten problems in RPM”

1. Michael Reinsch Says:
   June 13th, 2005 at 11:31 pm

   One comment to problem 10, “No provisions for interactive configuration scripts or human inspection/approval of new configuration files, and no concept of post-transaction configuration”:

   This should probably also go into another tool (same argument as in point 3).

   The easiest way I see to handle this would be to save the original, unaltered configuration file at some common place (maybe a rcs repository which then could also contain all previous versions; using tags one could easily retrieve them).
   A tool then could retrieve a patch containing only the changes made upstream and try to apply them (wiggle comes to mind here) and/or display the changes to the user.

   So, the important point is IMHO, that we keep the old, unaltered configuration file somewhere so that a patch can be computed.

2. athleston Says:
   June 14th, 2005 at 3:56 am

   First of all I read nearly all your postings and have enjoyed your series comparing the Connectiva - Mandriva build systems. Your analyses are great, keep up the good work.

   Now about the RPM issues. Have you looked at the work of the Electra project?: http://elektra.sourceforge.net/. From MPOV it is by design probably the best technology there is now for managing config info. But what do I know… what do you think?

3. Eduardo Habkost Says:
   June 14th, 2005 at 2:33 pm

   I agree with Michael about handling the configuration in an external tool. Probably some mechanism will be needed on RPM-or-its-sucessor, so the tool can be “notified” when it should act, and maybe storing some “configured” flag on the RPM-or-its-sucessor database.

   There are so many different ways of implementing this, that letting it be done by an external tool would be nice. So, e.g. the default handling could be similar to debian, but allowing it to be replaced by enhanced versions that do things such as storing all changes on a rcs repository.

4. El Panda Diablo Says:
   June 14th, 2005 at 8:04 pm

   Michael, Eduardo: yes, certainly this can be handled by an external tool (like debconf does with dpkg). The actual problem is that there’s no hook to call the procedure after all packages are installed. If we call it in post-install scripts, the entire installation process would have to be human-assisted, which can be tiresome in long transactions.

   athleston: I didn’t know Elektra, I’ll check it. Thanks for the comment and for reading the other posts!

5. Richard Says:
   June 16th, 2005 at 8:36 am

   Those answering about config tools in RPM - have you seen how DebConfig works? DebConfig allows the Debian packages to ask the user config questions, but abstracts away gow it’s done so the user is free to select text based dialogs, GUI, text files or “just take the defaults”.

   DPKG does have a source package system (or is it apt?) On Debian I can automatically fetch source code, build and output a deb file ready to install. I don’t have to be root to do this, (but do need to be root to install the resulting deb).

   Improvements I’d like would be patch support - differential updates to reduce download size. To make things easier for “Joe Pulic” though I’d like to see merge module support, so a distributer can include all dependencies with the package (on the CDROM perhaps) and install them if needed. This could be done at a layer above Dpkg or RPM. Apt solves the problem but only using its preconfigured package sources. Perhaps if Apt could be told to temporarily use the distribution CDROM or vendor web site as a package source when installing a given package, merge module like functionality could be implemented well.

   Merge modules are the one good thing about Microsoft’s installer. RPM and Deb however have far superior side by side installation support, dependency tracking, automatic cruft removal with Aptitude and even management tools.

6. Mikko Says:
   June 16th, 2005 at 8:40 am

   I’m not an expert on RPM or other package/build systems, but I’d add to (9) that the entire idea of ‘epoch’ is wrong. The version number, and no other number, should indicate the version. The epoch number is only needed because the version numbering is broken (problem 9). In my not so humble opinion non-numeral charactes in RPM version numbers should be banned alltogether; they should all be of the format package-1.2.3-4.5. If the version of the distro must be indicated, it should be the first number of the packaging release version (’4′ in the example). This was suggested for Fedora and it was used for a while, e.g. FC1 kernels were 2.4.23-1.1234 etc. but it has been replaced in FC3 by postfixing ‘_FC3′ in the package release version, which seems to me a step in the wrong direction

NewsForge Why I won't upgrade my Linux distribution

I'm not upgrading my Fedora Core 2 machine to Core 3, even though the new version has been out for a couple of months. There's not anything wrong with FC3 itself, it's just that system upgrades are both a blessing and a curse. I guess that's one of those dirty little secrets every Linux user knows, but that none of us talks about.

There are plenty of valid reasons not to upgrade to the latest release of your Linux distribution. You have to reapply all manner of preferences, hunt around in the new Applications menus to find where your programs have moved to and what they're called this time around, get used to new ways of doing the simplest tasks, and there's usually a new firewall subsystem to boot. But the one that has always gotten under my skin is the fact that upgrading my distro always breaks the add-on software I've installed myself.

If I'm lucky, it's just mangled. But on many occasions the installer program removes it entirely because it judges it a conflict with something new. In fact, every support forum I've looked at flat-out recommends that you do a clean install instead of attempting an upgrade. So it's guaranteed that whenever you upgrade, you'll have to reinstall everything from media players and games to commercial software and critical applications that just aren't mainstream enough for inclusion in the distro.

More and more people these days simplify package management with tools like apt and yum, and third-party package repositories like freshrpms, livna.org and Dag Wieers'. But the repositories and the distros each act like they live in separate worlds, and when upgrade time comes, it's the user who is inconvenienced.

Mainly you see this in the way the repository applications try to install virtually everything to /usr. According to the Filesystem Hierarchy Standard (FHS), /usr belongs to the system and should not be touched after initial installation. That may be a bit strict, but at the very least, binary packages should not be installing software to /usr that is canonically not part of the Linux distribution. If they'd just make that one change, I wouldn't have to re-install Mplayer after every upgrade.

Sure, it's not totally the packagers' fault -- the majority of software projects provide RPMs that install to /usr, in disregard of the FHS. You can force an RPM to install somewhere else with the --prefix switch, but only if it doesn't have any hard-coded paths, and a lot of them do. There are options to relocate individual files at install time, but that quickly gets impractical and might not work. But bad RPMs aren't the root of the issue.

This is a problem that already has a solution, and few people follow it: using /usr/local and /opt.

Following the FHS definition, any software you install yourself not from the distro really belongs in /usr/local. /usr/local is in every user's path, it contains the same bin and lib subdirectory structure that /usr does, and it won't get overwritten or mangled by a system upgrade that writes through /usr. If you write custom scripts, compile something from source, or install something self-contained (like Thunderbird and Sunbird tarballs), it finds its home in /usr/local.

There is some debate as to whether binary packages should follow the same policy. We encounter that old multiple personality disorder issue when installing a lot of RPMs -- you have to become root to do it, so in a sense you are becoming "the system" for a few minutes. But ultimately it's still you -- not the distro -- managing the application.

So what happens when you throw a third-party repository into this equation? You get /opt. The FHS defines /opt as the home for large packages from independent vendors. It used to be common for OpenOffice.org to reside in /opt, and before that, desktop environments like GNOME and KDE. That's no longer the case, though, as they're integrated enough in a modern Linux distro to belong in the main filesystem. But third-party software from repositories doesn't fit anywhere else, and they are independent vendors.

Here is what I propose:

• Every application project that offers independent downloads should package their RPMs to install in /usr/local.
• Third-party repositories should package their RPMs to install in /opt, under their own subdirectory.
• Distros should stick fast to the FHS definition of /opt and /usr/local, and never touch them.

I know, I know; it isn't that simple. I've discussed this ad nauseum and I know the criticisms. For one thing, two repositories could both provide the same package, and you end up with two copies in different directories. That's true, but it's really no worse than having both binaries try to install to /usr; the only difference is that the user will see the conflict after installation instead of before. It's broken either way.

For another, it doesn't necessarily solve the "fresh install" dilemma -- the only way that /usr/local and /opt would be preserved through a fresh install is if they are not on the main disk partition. Well, the solution to that is right there in the problem statement: put /usr/local and /opt on a separate partition by default. If that strikes you as too many partitions, well, you could always make /usr/local a symlink to a subdirectory in /opt and cut down a little. It even makes sense logically if you consider /usr/local a "vendor" according to the FHS usage of /opt.

You can't stop a pathological user from changing a partition setting and causing his own problems, but part of the distros' behavior modification needs to be acknowledging that their customers are going to need add-on software, so they must plan for it. Far from keeping its hands off of my /usr/local, Red Hat has even officially decided not to follow the FHS because it doesn't see the need. I say wake up and stick to the standard whether you enjoy it or not.

Sadly, there is no way to enforce this good behavior. Even if major projects like Mplayer and major repositories like DAG play by these new rules, others will not. So my final suggestion is that package-management programs start building in functionality to override or rescue poorly built packages. It'd be nice to see a flag in Synaptic when a package has hard-coded file paths -- and when it doesn't, to let me choose where to install it.

The point is, we live in a world where more and more users keep their machines up-to-date through live, over-the-wire package management. And no one vendor -- Linux distributions included -- provides absolutely everything. If we don't find a way for the different vendors to coexist and cooperate on one machine, then every increase in market share is going to bring with it an increasing number of frustrated and confused new users.

In closing, I have some exercises for the reader. Look up an install or upgrade guide for the distribution you are currently using. See how many packages it tells you you'll have to download separately when you're finished. Count how many of these you already have installed.

When you're done with that one, see if there is anything in /opt. On my system, the only packages that have installed themselves into /opt are Yahoo! Messenger and Quake 2. Kudos to the nice people who brought us both of those. If only everyone else would play nice, too.

[Sept 10, 2004] Linux Magazine September 2004 GURU GUIDANCE Creating Custom RPMs, Part Two

Last month's column looked at the basics of generating RPMs, including the format of the all-important .spec file. In theory, those principles should be enough to let you create .spec files and RPMs for a number of purposes. In practice, however, RPM generation is complex enough that some examples are sure to help. So, this month's column presents two examples: creating a non-program RPM and creating a program RPM.

short sighted (Score:1, Interesting)
by Anonymous Coward on Monday March 19, @10:47AM EST (#115)

Though I agree that this initially appears to fit well with RedHat's desire to make money off of service, I think it is incredibility shortsighted. Most automated update tools are made because they help offset service cost for known issues especially in consumer space where there the cost overshadows the potential revenue.

RedHat is in the public eye as well and they need to ensure that people are upgrading promptly when new security holes are found. The Ramen worm could have easily been avoided if people had kept up with security updates. I personally don't have the time to keep up with security advisories and also compare whats on my system with every new update.

I'll use red-carpet for now but I may consider switching back to Debian.

Slashdot No More Free Updates For Red Hat

An anonymous user wrote in to tell us (and Timothy called RH and confirmed, this change was made a few weeks ago) that you no longer can Freely and Anonymously use Red Hat's Update Agent to download updated package DBs, and update packages. You must register, and pay $9.95 for the service. Of course you can still update manually, but how long before other services pop up to take its place? And Debian still does apt without me having to tell them where I live. This is unfortunate, but not unsurprising. I want RH to make a buck too, but this seems like a pretty crappy way to do it. Update: 03/19 03:21 PM by T : An unnamed reader points to this FAQ on the change, too.

Try updateme (Score:1) by Sc00ter (travis@scootz.net) on Monday March 19, @10:42AM EST (#108) (User #99550 Info) http://www.scootz.net

http://www.uga.edu/ucns/wsg/linux/updateme/ Updateme is free, and does the same basic function.

Didn't Ximian already beat them to the punch? (Score:1) by tweder (scott2porteighty.com (2 == @)) on Monday March 19, @10:41AM EST (#105) (User #22759 Info) http://porteighty.com

Correct me if I'm wrong, but doesn't Ximian's Red Carpet utility do the same this as Redhat's update agent? I don't see the problem, since someone else is providing a _free_ means to the same end. Plus Red Carpet is a far more attractive, professional looking utility, IMNSHO.

Oh no!!! (Score:1) by hansendc on Monday March 19, @10:28AM EST (#55) (User #95162 Info) http://www.sr71.net

Because of its all in all crappy command line interface, I gave up on up2date on my machines that don't have X. I use rhup, a free (you don't get charged ten bucks to use it) utility to download updates for you.

I've never gotten up2date to work well for me. Instead, I've been using a script that parses rpmfind.net output and automagically installs stuff for me. Considering this news, I'm releasing the script to the public (something I didn't want to do because if rpmfind changes, the script breaks). Here is the link to the script. Please mirror, etc, as this is a cable line, and my wife's website (the reptile shelter in my sig) will go down if this site goes down. -Want an iguana?

[

Pennies from heaven (Score:2, Insightful) by Darth RadaR on Monday March 19, @10:39AM EST (#99) (User #221648 Info)

I don't know why anyone is whining. You can still download Redhat for free, so if you have to set up a box, no problem. Redhat is a company filled with people who have to eat, pay rent, etc. $9.95 is not too bad when you consider the M$ option. If you're going to use Redhat software and expect updates, don't be such a leech by demanding everything free. If you don't like it, then use another distro. Besides, I feel that if one actively supports open-source software, then they'll be decent enough to put some money into it. Eventually, no money == no open-source software. /*drunk.. fix later*/

[

Didn't Ximian already beat them to the punch? (Score:1) by tweder (scott2porteighty.com (2 == @)) on Monday March 19, @10:41AM EST (#105) (User #22759 Info) http://porteighty.com

Correct me if I'm wrong, but doesn't Ximian's Red Carpet utility do the same this as Redhat's update agent? I don't see the problem, since someone else is providing a _free_ means to the same end. Plus Red Carpet is a far more attractive, professional looking utility, IMNSHO.

Re:Didn't Ximian already beat them to the punch? by tweder (Score:1) Monday March 19, @11:32AM EST 1 reply beneath your current threshold.

Try updateme (Score:1) by Sc00ter (travis@scootz.net) on Monday March 19, @10:42AM EST (#108) (User #99550 Info) http://www.scootz.net

http://www.uga.edu/ucns/wsg/linux/updateme/ Updateme is free, and does the same basic function.

rpm -i foobar-1.0-1.i386.rpm

The next simplest command is to uninstall a package:

rpm -e foobar

One of the more complex but highly useful commands allows you to install packages via FTP. If you are connected to the net and want to install a new package, all you need to do is specify the file with a valid URL, like so:

rpm -i ftp://ftp.redhat.com/pub/redhat/rh-2.0-beta/RPMS/foobar-1.0-1.i386.rpm   

Perl modules and utlities:

Why not use Fedora Legacy's yum repositories? (Score:5, Informative)
by rklrkl (554527) on Thursday January 15, @06:46PM (#7992429)
(http://lottery.merseyworld.com/)

I set up yum recently on Red Hat 8.0 and pointed it to the appropriate repositories [duke.edu] - a free way to get backported security fixes for 8.0. A shame that Red Hat never mentioned this as an option in their e-mail to all the RHN subscribers...

Comparing Linux-UNIX Binary Package Formats

This is a comparison of the deb, rpm, tgz, slp, and pkg package formats, as used in the Debian, Red Hat, Slackware, and Stampede linux distributions respectively (pkg is the SVr4 package format, used in Solaris). I've had some experience with each of the package formats, both building packages, and later in my work on the Alien package conversion program.

I've tried to keep this comparison unbiased, however for the record, I'm a fan of the deb format, and a Debian developer. If you discover any bias or inaccuracy in this comparison, or any important features of a package format I have left out, please mail me so I can correct it. Several people have already done so. I'm also looking for data to fill in the places marked by `?'.

This comparison deals only with the package formats, not with the various tools (dpkg, rpm, etc.), that are used to deal with and install the packages. It also does not deal with source packages, only binary packages.

broadband » Forums » All things UNIX » RPM quickie cheat sheet

RPM quickie cheat sheet

I sometimes see a few rpm queries and questions that pop up over time. I work a lot with RPM, and I have compiled a quick cheat sheet. It is by no means complete. I am suprised a lot of people don't know that you can install rpms by wildcard, and also specify multiple rpms on the command line (also with wildcards). (like rpm -i IBMJava2-SDK*.rpm IBMJava2-JRE*.rpm). The neat thing here is rpm will work out the correct order to install the RPMS to satisfy dependencies .. not you.

Install an RPM:

rpm -i rpmname.rpm - is the most basic use.

Remove an RPM:

rpm -e rpmname.rpm - is the most basic use

Note: When you remove an rpm, you should not specify the arch.rpm extensions (commonly it is i386.rpm).

Upgrade an RPM:

rpm -U rpmname.rpm - is the most basic use (though common options are -Uvh)

All of these commands have many, many modifiers. Here are some of the ones I use most frequently

--excludedocs - will leave out man files, docs files, info files from the install

--test - mock install/remove/etc. Don't really do it, but see if it works.

-v --hash - draw a progress bar of the install/remove/etc

--force - force an installation (can really mess up the database)

--nodeps - Don't check for dependencies (can really mess up the database)

Querying an rpm

There are several ways to query an rpm:

List all rpms in the system:

rpm -qa

List all files in an rpm (in this case one that has been installed):

rpm -ql rpmname

Note: Again do not specify the .arch.rpm. Also this does not have to be the full name of the rpm. Partial names work too.

List all the files in an rpm file that has not been installed on your system

rpm -qp rpmname.rpm -ql

List all the files in an rpm file that has not been installed on your system, but you have on disk. Also print a brief summary of the package function:

rpm -qp rpmname.rpm -ql --info

List all the files in an rpm file that has not been installed on your system, and does not exist on your system. Query over ftp. Also print a brief summary of the package function

rpm -qp

ftp://ftp.redhat.com/pub/redhat/linux/8.0/en/os/i386/RedHat/RPMS/zlib-1.1.4-4.i386.rpm

-ql --info

(the above goes on one line)
You see the query options can build on top of each other.

More advanced queries when I type em up ...

I'd also like to see other folks rpm tips.

[text was edited by author 2003-02-20 22:54:42]
LittleZoper(anon)

  Ever wonder what RPM a file belongs to? Try this:

rpm -q --whatprovides

You can also do this to find the RPM for an executable file of sort:

rpm -q --whatprovides `which `

I have a script in /usr/local/bin/ called whichrpm that looks like this:

#!/bin/bash

for FILE in $* ; do
echo -n $FILE: `rpm -q --whatprovides $FILE`
echo
done
--
jason

Recommended Links

RPM Package Manager - Wikipedia, the free encyclopedia

www.rpm.org homepage - RPM Package Manager

• RPM Site - Hints and Links -- Quick Questions and Answers

Maximum RPM

Reference

Linux.com RPM cheat sheet

Linux rpm cheat sheet

RPM Cheat Sheet

rpm_cheat_sheet

rpm man page

broadband » Forums » All things UNIX » RPM quickie cheat sheet

RPM quickie cheat sheet

I sometimes see a few rpm queries and questions that pop up over time. I work a lot with RPM, and I have compiled a quick cheat sheet. It is by no means complete. I am suprised a lot of people don't know that you can install rpms by wildcard, and also specify multiple rpms on the command line (also with wildcards). (like rpm -i IBMJava2-SDK*.rpm IBMJava2-JRE*.rpm). The neat thing here is rpm will work out the correct order to install the RPMS to satisfy dependencies .. not you.

Install an RPM:

rpm -i rpmname.rpm - is the most basic use.

Remove an RPM:

rpm -e rpmname.rpm - is the most basic use

Note: When you remove an rpm, you should not specify the arch.rpm extensions (commonly it is i386.rpm).

Upgrade an RPM:

rpm -U rpmname.rpm - is the most basic use (though common options are -Uvh)

All of these commands have many, many modifiers. Here are some of the ones I use most frequently

--excludedocs - will leave out man files, docs files, info files from the install

--test - mock install/remove/etc. Don't really do it, but see if it works.

-v --hash - draw a progress bar of the install/remove/etc

--force - force an installation (can really mess up the database)

--nodeps - Don't check for dependencies (can really mess up the database)

Querying an rpm

There are several ways to query an rpm:

List all rpms in the system:

rpm -qa

List all files in an rpm (in this case one that has been installed):

rpm -ql rpmname

Note: Again do not specify the .arch.rpm. Also this does not have to be the full name of the rpm. Partial names work too.

List all the files in an rpm file that has not been installed on your system

rpm -qp rpmname.rpm -ql

List all the files in an rpm file that has not been installed on your system, but you have on disk. Also print a brief summary of the package function:

rpm -qp rpmname.rpm -ql --info

List all the files in an rpm file that has not been installed on your system, and does not exist on your system. Query over ftp. Also print a brief summary of the package function

rpm -qp

ftp://ftp.redhat.com/pub/redhat/linux/8.0/en/os/i386/RedHat/RPMS/zlib-1.1.4-4.i386.rpm

-ql --info

(the above goes on one line)
You see the query options can build on top of each other.

More advanced queries when I type em up ...

I'd also like to see other folks rpm tips.

[text was edited by author 2003-02-20 22:54:42]
LittleZoper(anon)

  Ever wonder what RPM a file belongs to? Try this:

rpm -q --whatprovides

You can also do this to find the RPM for an executable file of sort:

rpm -q --whatprovides `which `

I have a script in /usr/local/bin/ called whichrpm that looks like this:

#!/bin/bash

for FILE in $* ; do
echo -n $FILE: `rpm -q --whatprovides $FILE`
echo
done
--
jason

Tutorials

• rpmhelp.net - RPM Creation Help and Information
• MUO - GNU-Linux Basics - RPM III
• LinuxNewbie.org: Apt NHF(Jan 03, 2001)
• LinuxNewbie.org: RPMs: Dependencies(Dec 23, 2000)
• Freshmeat: An RPM port of APT(Dec 02, 2000)
• FreeOS.com: RPM usage for newbies(Oct 21, 2000)
• Freshmeat: Is it time to change RPM?(Sep 16, 2000)
• Linux.com: An Introduction to Packages and the RPM System(Jun 10, 2000)
• Package management using apt-get in Debian(Jan 27, 2000)

Keeping your software up to date

Red Hat Package Manager (RPM)

AutoRPM (http://www.kaybee.org/~kirk/html/linux.html) - Written by Kirk Bauer, it is an automation tool for syncing your OS with patches stored on an FTP site. It can also be used to sync a network or cluster. It works by checking a list of FTP sites specified in its configuration file for upgrades. If any upgrades are found it will automatically or manually install the upgrades. It is one of the best utilities for the Red Hat Package Manager system.

Red Hat Network (http://www.redhat.com/network) - Red Hat has their own automation tool for package management and deployment. Its called Red Hat Network and it works by syncing your system to a profile that you set up. First you sign up for an account (Which costs a fee a month, free trial though) and send your hardware/software configuration to Red Hat. Then when updates are available it automatically installs them. One drawback is that it can only update packages from the Red Hat distribution and power tools collection.

YUP (http://devel.yellowdoglinux.com/rp_yup.shtml) - YUP is a program similar to apt-get in functionality. It will automatically scan a site for update packages and install them. In addition, it offers the ability to remove and install new packages specified.

Glyphic RPM Updater (http://www.glyphic.com/free/RpmReadMe.html) - Glyphic RPM Updater is a utility good for updating packages from update CD-ROMs. It works by creating a list of RPM files off a CD-ROM (or other media) and installs newer versions of packages it detects. If you get monthly update CD-ROMs this utility can come in handy.

Debian Package Manager (DPKG)

Apt (http://www.debian.org) - APT is part of the Debian distribution and it is the best utility for package management and deployment. It works by checking FTP sites specified in its configuration file for updates, and if available it installs them. In addition, it can automatically install the package dependencies needed for the updates to run, and gives you the ability to remove, install, and upgrade packages. It can update specific packages or do system-wide software updates. It is also a joy to use.


GNOME Apt(ftp://ftp.debian.org/mounts/u2/mirrors/debian/dists/potato/main/binary-i386/admin/) - A GNOME-based version of the same great utility Apt. It's features all the great features of Apt in an easy to use GUI interface. While it does not add any new features it does provide a nice user experience.

Conclusion

Package management has come a long way since Linux's birth.

RPM-based checking

www.rpm.org homepage - RPM Package Manager

The stated early (10 November 2002) roadmap for that new rpm-4.2 release is to include:

a) file classes (think: sanitized file (1) output in dictionary, per-file index).

b) file color bits (think: 1=elf32, 2=elf64).

c) attaching dependencies to files, so that a refcount is computible.

d) replacing find-{provides,requires} with internal elfutils/file-3.39.

e) install policy based on file color bits

f) --excludeconfig like --excludedocs with the added twist that an internal Provides: will be turned off, exposing a Requires:. This will provide a means to install all %config files from a separate package if/when necessary.

and teaching tripwire to read file MD5's from an rpm database.

rpm-4.2 will be the next release of rpm.

One nice feature of the RPM system is the -V (verify) option which allows you to get a handy list of which files differ between the package database records and their actual nodes in the filesystem. Thus you can see size, MD5 checksum, and especially ownership and permission differences which might be causing problems. Naturally it will also warning of any missing files.

If you suspect that your system is compromised, you can use the command:

                        root# rpm -Va

to verify each file on the system. See the RPM man page, as there are a few other options that can be included to make it less verbose. Keep in mind you must also be sure your RPM binary has not been compromised. RPM can also be combined with PGP to check a package's signature. Typical output might look like the following:

                          ..5....T /bin/login

should sound alarm bells. RPM produces the following useful output fields:

• S - file size changed
• M - file mode changed
• 5 - MD5 checksum failed
• U - file owner changed
• G - group changed

This means that every time a new RPM is added to the system, the RPM database will need to be re-archived. You will have to decide the advantages versus drawbacks. Also, keep in mind that it won't verify programs that RPM did not install.

Specifically, the files /var/lib/rpm/fileindex.rpm and /var/lib/rpm/packages.rpm most likely won't fit on a single floppy. Compressed, each should fit on a separate floppy. Consider storing this (as well as the actual /bin/rpm executable!!) on a Zip cartrige.

RPM-related PERL Modules and Utilities

• Perl-RPM Perl bindings for the rpm 3.0.X API.Author: Randy J. Ray

• RPMTools  A set of Perl scripts to manage RPM files.

• rpmerizor A small utility which lets you use rpm as a simple archiver.

• rpmwatch Keeps your RPMs in sync with the official errata

• RPM PAN A script to generate an RPM repository of CPAN Perl modules.

• rpmproc simple Perl wrapper to help manage and build RPM packages

• rpmstatus A tool for generating Web pages listing installed RPMs

• Gtk::RPMmerizor A graphical frontend for the rpmerizor.

• AutoUpdate Automatically upgrades RPM-based systems via (S)FTP or HTTP(S).

• RPM PAN A script to generate an RPM repository of CPAN Perl modules.

• AutoUpdate Automatically upgrades RPM-based systems via (S)FTP or HTTP(S).

• relink An application/package management utility

• lesspipe.sh A preprocessor (input filter) for less.

Creating custom RPMs

[Aug 10, 2004] Linux Magazine August 2004 GURU GUIDANCE Creating Custom RPMs, Part One

RPMs can be a great way to manage the packages you install on your system. Unfortunately, not everything you might want to install is available in RPM form. Perhaps you need a more recent version of a program than the one that ships with your distribution; or maybe it's a program you wrote yourself; or perhaps it's just something that's very obscure. Similar dilemmas can occur with non-program packages, such as font or clip art collections.

Whatever the case, if you're installing a program for a single computer, chances are you'll just install it the old-fashioned way, by typing make && make install (or some similar set of commands) in the source directory. make gets the job done, but it means you're giving up the benefits of the RPM system. What's more, if you're maintaining several computers, running around installing the same package on all of them can be tedious.

Life would be much easier if you could create your own RPM, giving you the ability to easily install the package on many systems and the benefits of its package tracking. Fortunately, RPM includes tools that enable you to do just that. Creating an RPM isn't as easy as creating a tarball, but the task isn't insurmountable.

This month's column covers the files and file formats involved in creating RPMs. Next month's column will present practical examples, including how to build both binary and architecture-independent RPMs.

Last modified: April 03, 2008