[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SEUL: Description of RPM
I feel than before deciding what distribution will be our basis. We
need to review the distributions we know.
Because the discussion is now centered in package managers I will
describe RedHat's Package Manager (RPM).
For DEbian or RedHat users the description of the functionalities of
RPM can seem to describe obvious things but Slackware users are not
used to package managers.
In the rest of this message RPM means the upgrading software and RPMs in
plural means software packaged in the rpm format.
RedHat comes with a text based package manager RPM and a graphic front
end called GLINT. Both are licensed under the GPL.
RPM allows the install, clean uninstall and upgrade in place of
packages. It will detect conflicts between packages. It will save
modified config files so you will not have to rewrite them. However
it always install a new config file so you have to restore your old
files. This could be improved if RPM had the notion of a minimum
version where config file is valid: for instance if you are upgrading
from version 6 to version 7 you can use the old config file so it is
always kept in place, but if upgrading from version 5 then file format
has changed so save the old and install a new one.
RPM will not allow you to downgrade unadvertendly.
RPM will start installation and uninstallation scripts if included in
the package. Typical use of this is automatic configuration and
cleaning. Also rebuilding of the dynamic linker cache if the package
includes shared libraries.
RPM has the notion of dependencies: it will not install a package if
something needed is not present: for instance it will not install
something relying on TCL if TCL is not present and if your package
relies on a range of a versions of TCL then RPM will check it. Also
RPM will not unisntall something needed by other packages still
installed unless you override it with --nodeps.
Dependencies is a very cool feature, specially for non-experts: it is
a very good insurance against disasters like uninstalling the dynamic
libc. However it appears from the news traffic than some people are
confused by dependencies perhaps because rpm messages are terse
in the typical Unix fashion.
RPM allows you to check if a package is installed, list its files,
know its size, date of installation and builder, check if files in the
package have been altered or destoyed since installation. You can get
the complete list of the packages installed.
The shortcomings of RPM respective to DPKG is than dependencies in RPM
is an all or nothing affair. DPKG has the notion of recommended
packages: a secondary package not strictly necessary but who will make
your life easier with what you are installing. This is probably a
minor point. More serious is than RPM does not have the notion of
unconfigured package: either it configures it without querying you for
parameters or it lets you do it. In DPKG there is the notion of
configured or unconfigured state that allow to query what are the
unconfigured packages and run a configuring software than can query
you for parameters. On the other side notice than RedHat provides
configuration tools for a fair number of things and these tools are
GPLed
There are lots of RPM packaged software in the net outside those made
by RedHat. However some are better built than others. I have read an
announce about last versions of ALIEN allowing to translate DPKGs into
RPMs in addition to the RPM to DPKG conversion but I have not tested
this personally.
RPM is a line mode utility very Unix-like in its use. GLINT is its
graphical front end. It allows you to select packages and do a subset
of what RPM allows. It compares what is installed with the packages
in a directory and will only show the differences. The packages are
listed by categories in a tree-like structure. However Glint is
seriously brain damaged.
One of the problems than it does not give any visual indication when
the version in the directory is older than the one istalled. And
for installs and upgrades it runs RPM with the --force argument so it
will happily overwrite files belonging to other packages and will
downgrade software if you are not very careful. If you select a bunch
of packages and one of them lacks a dependency then GLINT installs
NOTHING, futhermore it gives no message, so you don't know what
package was wrong and what dependency was lacking, besides GLINT does
not allow you to query dependencies, you have to use RPM. To compound
all this GLINT unselect ALL packagges you selected so you have to
begin anew.
Notice however than it would be easy to hack glint in order to remove
these shortcomings:
1) Give a visual indication when the version in the directory is
older than the one installed
2) Use rpm in normal mode and if the installation fails due to
conflicts then ask about using --force.
3) As a minimum give a list of the dependencies failed (rpm gives it
to GLINT but GLINT discards it)
Also people of RedHat have claimed than next RedHat distribution will
ship with an improved GLINT.
In conclusion I find than RPM is a good package manager despite being
slightly less powerful than DPKG. On the other side I think there is
more ssoftware packaged with RPM than with DPKG. However GLINT really
needs some brain surgery, but it would be easy and there is a chance
than RedHat will make the work for us.
--
Jean Francois Martinez
==================== The Linux. Use the Linux, Luke! =======================
----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------