|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
RPM 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". Right now
YUM is often used as an alternative.
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.
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 de-installed 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.
--aid option: installing packages with dependencies
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
Here is the explanation of --aid
option from
faqcentos [Sample - DokuWiki]
rpm -i --aid package
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
Before option --aid was available the typical way to install a package
with dependencies was trial and error process, for example let's try to
install Apache:
# 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
We see that we cannot install it directly as some libraries are not yet
installed. This "dependency" problem is typical for large and complex packages.
To solve this problem you can use
# rpm -qp --provides http-2.0.4-9.i386.rpm
libhttp.so.2
Now we know which package provides the missing library. And since the
package name itself is "http," we can be fairly safe in assuming that "http"
will be provided too. Now, the "-qp --provides" arguments to RPM told it
to go into query mode ("-q"), to query an uninstalled package file ("p"),
and to list what it provides ("--provides"). A list of more functions is
available by typing "rpm --help | less" or simply "man rpm".
# rpm -Uvh http-2.0.4-9.i386.rpm
http
##################################################
Note usage of "-Uvh" as argument
to rpm. This told it to Update/install a package, be
verbose about it (give detailed information on what it
is doing), and print hash marks as a progress meter. If
http had been installed already, the use of "-U" would give rpm the ability
to update the package from an earlier version. To check what files were
added use:
# rpm -ql http
We just asked rpm to view its central database we mentioned earlier,
and to tell us what files it knows of that belong to this http package.
if you've made a mistake, and want to get rid of the server, this
is generally no hassle with packages. Here's how it's done:
# rpm -e http
To re-check type it again: rpm -ql http
If you actually haven't got the prerequisite packages installed you can
try "rpm -Uvh --nodeps filename.rpm"
However, this can lead to problems later.
A quick way to check on what a particular package is. This is achieved
by the use of "rpm -qpi" for uninstalled packages, or "rpm -qi" for installed
packages. For example:
# rpm -qpi http-2.0.4-9.i386.rpm
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]).
The most frequently used rpm options (packagename below is just
mane, it does not need to contain version or extension (.rpm))
rpm Va -- verify all packages (you need to grep for
interesting information)rpm --verify (-V)[name] will tell you if all files
of the packages are still (or at all) installed.- rpm -Vp rpmfile verifyes
installed package against zip package headers
In case of failed verification rpm displays one or several RPM Verification
Codes. Among them:
- S -- File size has changed
- M -- Mode has changed, including file permissions and file
type
- 5 -- MD5 sum has changed
- D -- Device major or minor number has changed
- L -- The path of the symbolic link has changed
- U -- The owner of the file has changed
- G -- The group of the file has changed
- T -- The last modified time has changed
- 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.
-
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
rpm -qf <filename>
rpm
-qf /usr/bin/w #
the package which owns the file
The <filename> must be the full path to the file. If the file
is associated with an RPM package installed, the name of the package
and the version installed is displayed. For example, if the rpm
-qf /etc/crontab command is issued, the output is crontabs-<version>-<release>,
where <version>-<release> is the version and release of the
crontabs package installed.
Tip: If the file is a command already in your PATH environment variable,
use the following syntax instead of typing the entire path to the file,:
rpm -qf `which <filename>`
- rpm -qc <packagename> To retrieve a list of configuration files
from a package installed, use the following command:
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 instlalled package is about, who packaged it etc.
-
To list any documentation files installed with a package:
rpm -qd <packagename>
Each time a package is changed, the developer is responsible for
adding a changelog entry to describe the change. This becomes part of
the information provided by the RPM package. The query option has the
ability to show the changelog for the package with the following command:
rpm -q --changelog <packagename>
These query commands can also be performed on an RPM package file
instead of on the package name of the package already installed. To
do so, add the -p argument followed by the full or relative
path to the package file. For example, to view the changelog of a package
before installing it, use the following command:
rpm -q --changelog -p <packagename>-<version>-<release>.<arch>.rpm
1. rpm2cpio is the tool you'd need, to turn the RPM file into a CPIO
stream, which you then pipe through cpio to extract to disk. For example
(File and Archiving Commands)
Unpacking an
rpm archive
1 #!/bin/bash
2 # de-rpm.sh: Unpack an 'rpm' archive
3
4 : ${1?"Usage: `basename $0` target-file"}
5 # Must specify 'rpm' archive name as an argument.
6
7
8 TEMPFILE=$$.cpio # Tempfile with "unique" name.
9 # $$ is process ID of script.
10
11 rpm2cpio < $1 > $TEMPFILE # Converts rpm archive into cpio archive.
12 cpio --make-directories -F $TEMPFILE -i # Unpacks cpio archive.
13 rm -f $TEMPFILE # Deletes cpio archive.
14
15 exit 0
16
17 # Exercise:
18 # Add check for whether 1) "target-file" exists and
19 #+ 2) it is really an rpm archive.
20 # Hint: parse output of 'file' command.
|
2. You can install an rpm to an arbitrary root directory (e.g.
targetdir)
placing the package files under targetdir and the rpm database in the
targetdir/var/rpm directory with something like:
rpm -ivh --nodeps --relocate /=targetdir
--root=targetdir package.rpm
3. Suse has unrpm, which been part of the distribution for a long
time
4. using mc. This can enter and view the files inside the rpm,
viewing not just the directory structure, but the init script itself
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"
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
== Query / Verify commands
- Getting detailed information about the package wget:
rpm -qi wget
- Determining which package installed the file /usr/bin/wget:
rpm -qf /usr/bin/wget
- Showing all the files installed by the package wget:
rpm -ql wget
- Viewing the documentation files for the command wget:
rpm -qd wget
- Listing all files included in the not yet installed package wget by
entering the following:
rpm -qpl /mnt/iso/suse/i586/wget-1.10.2-78.i586.rpm
- Listing all files included in the installed package wget:
rpm -ql wget
- Verifying that a package is no longer installed by entering:
rpm -qa | grep wget
- Seeing what has changed in the files on your hard drive since the
wget RPM was originally installed by entering the following:
rpm -V wget
- Checking package to ensure its integrity and origin: (NOTE: gpg or
pgp software must be installed on your system before you use this
command)
rpm -K /mnt/iso/suse/i586/wget-1.10.2-78.i586.rpm
|
|
Notes:
- This is a Spartan WHYFF (We Help
You For Free) site written by people for whom English
is not a native language.
Some amount of grammar and spelling errors should be
expected.
- The site contain some broken links
as it develops like a living tree...
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.
|
|
|
1. rpm2cpio is the tool you'd need, to turn the RPM file into a CPIO
stream, which you then pipe through cpio to extract to disk
2. You can install an rpm to an arbitrary root directory (e.g. targetdir)
placing the package files under targetdir and the rpm database in the
targetdir/var/rpm directory with something like:
rpm -ivh --nodeps --relocate /=targetdir
--root=targetdir package.rpm
3. Suse has unrpm, which been part of the distribution for a long
time
I would suggest using mc. This can enter and view the files inside the
rpm, viewing not just the directory structure, but the init script itself
12 Jan 2010
Article ID: 6928 - Created on: Apr 22, 2004 6:00 PM - Last Modified:
Feb 17, 2009 10:19 AM
Release Found: Red Hat Enterprise Linux
The
rpm -qf command will provide
the name of the RPM package that contains a specific file. For example,
to see which rpm contains the file
/usr/lib/libdb.so.2, run
the following:
#
rpm -qf /usr/lib/libdb.so.2
gnome-libs-1.4.1.2.90-34.1
If
you are trying to install an RPM package and you are getting an error
message saying that a file is missing, RPM may not be able to tell you
which package that file is in. In this case, the third party web site
http://www.rpmfind.net is a good resource. This website allows you
to search by file, and then prints out the name of the package that
file is in.
Once you know which package you need to install, you can use
up2date in Red Hat Enterprise
Linux 4 and older, or yum
in Red Hat Enterprise Linux 5 and newer, to install the package from
RHN. Packages can also be downloaded from the RHN website at
http://rhn.redhat.com.
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.
freshmeat.net
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
freshmeat.net
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]
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}
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 preferably 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:
- 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.
- 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.
- 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.
- Obtuse macro expansion and commentary handling
in specfiles. Macros expand inside comments, and line breaks cause
unexpected behavior.
- Absence of logical OR in requirements forces
the developer to always regenerate all alternative packages to provide
virtual packages.
- Incomplete timestamp format in specfile changelogs.
Standard
date(1) format or other providing time of
change is needed.
- 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.
- 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).
- Non-intuitive (or plain broken) algorithm to
compare package versions (example: 1a > 1B) . Epoch zero is considered
newer than no epoch at all.
- 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.
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.
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.
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.
|
|
|
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:
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 utilities:
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...
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.
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
In case of broken links
please try to use Google search. If you find the page please notify
us about new location
RPM Package Manager - Wikipedia, the free encyclopedia
www.rpm.org
homepage - RPM Package Manager
Maximum
RPM
1.
An Introduction to Package Management
-
What are Packages, and Why Manage Them?
-
Package Management: How to Do It?
-
RPM Design Goals
-
What's in a package?
-
Let's Get Started
2.
Using RPM to Install Packages
-
rpm -i — What does it do?
-
Performing an Install
-
Two handy options
-
Additional options to rpm -i
3.
Using RPM to Erase Packages
-
rpm -e — What Does it Do?
-
Erasing a Package
-
Additional Options rpm man page
-
-
rpm -e and Config files
-
Watch Out!
4.
Using RPM to Upgrade Packages
-
rpm -U — What Does it Do?
-
Upgrading a Package
-
They're Nearly Identical…
5.
Getting Information About Packages
-
rpm -q — What does it do?
-
The Parts of an RPM Query
-
A Few Handy Queries
6.
Using RPM to Verify Installed Packages
-
rpm -V — What Does it Do?
-
When Verification Fails — rpm -V Output
-
Selecting What to Verify, and How
-
We've Lied to You…
7.
Using RPM to Verify Package Files
-
rpm -K — What Does it Do?
-
Configuring PGP for rpm -K
-
Using rpm -K
-
search
RPM package is a powerful utility for managing the software
packages of major Linux distributions. RPM can be used to
install and remove software packages, update packages and get an
overview of all installed packages.
Here are some useful commands to manipulate RPM packages:
== Query / Verify commands
- Getting detailed information about the package wget:
rpm -qi wget
- Determining which package installed the file
/usr/bin/wget:
rpm -qf /usr/bin/wget
- Showing all the files installed by the package wget:
rpm -ql wget
- Viewing the documentation files for the command wget:
rpm -qd wget
- Listing all files included in the not yet installed
package wget by entering the following:
rpm -qpl /mnt/iso/suse/i586/wget-1.10.2-78.i586.rpm
- Listing all files included in the installed package
wget:
rpm -ql wget
- Verifying that a package is no longer installed by
entering:
rpm -qa | grep wget
- Seeing what has changed in the files on your hard drive
since the wget RPM was originally installed by entering the
following:
rpm -V wget
- Checking package to ensure its integrity and origin:
(NOTE: gpg or pgp software must be installed on your system
before you use this command)
rpm -K /mnt/iso/suse/i586/wget-1.10.2-78.i586.rpm
== Install / Uninstall / Upgrade commands
- Installing the package wget:
rpm -ivh /mnt/iso/suse/i586/wget-1.10.2-78.i586.rpm
- Uninstalling the package wget:
rpm -e wget
- Upgrading the package wget: (NOTE: if the package is not
installed it will install it for You, like option "-ivh")
rpm -Uvh /mnt/iso/suse/i586/wget-1.10.2-78.i586.rpm
- Extracting RPM file using rpm2cpio and cpio command:
(NOTE: RPM content will be extracted the current directory)
rpm2cpio wget-1.10.2-78.i586.rpm | cpio -idmv
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 sheetI 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 |
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.
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.
-
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.
Etc
Copyright © 1996-2009 by Dr. Nikolai Bezroukov.
www.softpanorama.org was
created as a service to the UN Sustainable Development Networking Programme (SDNP)
in the author free time.
Submit
comments This document is an industrial compilation designed and created
exclusively for educational use and is placed under the copyright of the
Open Content License(OPL).
Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made
for educational purposes only in compliance with the fair use doctrine.
Disclaimer:
- The statements, views and opinions presented on
this web page are those of the author and are not endorsed by, nor do they necessarily
reflect, the opinions of the author present and former employers, SDNP or any other
organization the author may be associated with.
- We do not warrant the correctness of the information provided or its
fitness for any purpose
- In no way this site is associated with or endorse cybersquatters
using
the term "softpanorama" with other main or country domains (e.g. softpanorama.com) with
bad faith intent to profit from the goodwill belonging to
someone else.
Last modified:
February 08, 2010
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.
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?
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.
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!
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.
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