Red Hat Bugzilla – Bug 536
Suggestions to improve RPM
Last modified: 2007-04-18 12:22:11 EDT
The following enhancements would provide major improvements
to RPM, both in terms of its utility and ease of use by
novices. If they currently exist, they are not described
in the man page.
1. Add an option to install updates to installed packages
only. The option would specify a directory of update
rpms and would update only those packages that are
already installed on the system. See scripts at URL for
a crude and inefficient proof-of-concept shell-script
implementation. Users could grab the updates directory
with wget and run a single command to do the update.
Further, it would be the same commands each time. It
requires much less work than the current situation, and
a lot less knowledge. It could (should) even be placed
as a button on the control panel. Doing this would
vastly increase the number of users updating their
systems, and would decrease support load. The directory
specification should name a tree top, and rpm should
descend the tree looking for all rpm packages. This
allows flexibility: the directory could contain the
rpms, or i386 and noarch directories, or even copies of
update directories from several rpm creators.
2. If actions beyond what rpm does are required, rpm -U
should print them on the screen. For example, lilo
after kernel updates.
3. Add a path variable of directories containing rpms.
When specifying multiple rpms on an update command line,
retyping the directory name is tedious and error-prone.
See tree-top directory format mentionned in item 1.
4. Include an indicator in the rpm -V file modification
flags for log file, similar to the one for configuration
file. A log file would be any file that is expected to
change in the normal course of operations, but (unlike
config files) without the user's knowledge or
participation. Files in this category would include
traditional logs and files like:
all kernel .depend files
all kernel headers that get touched with each build
5. Add an option to rpm that will extract the package's
files (including scripts) under a specified directory,
not run any scripts, and not record the package as
installed. This allows the inspection of rpm contents,
and the restoration of individual files that have been
damaged on the system without overwriting changes made
to other files in the package.
6. Add an option to extract a single file or set of files
from an rpm.
7. Make rpm work better as a tool for system disk
a. Add options to rpm -V that ignore changes to log
and/or configuration files.
b. Add a global verify command that is something
foreach i (`rpm -qa`)
rpm -V $i
... but only prints the package name and results
if the verify fails. In effect, this would be a
system verifier with capabilities similar to
c. Add an option to the global verifier (previous
item) that would restore any corrupt/missing
files from their rpms. Pay attention to options
that say to ignore changes to configuration or
log files. The rpm path variable mentionned
above would be needed to do this.
d. Add an option to identify a file and its package
by its md5sum. This would be a major help in
recovering items from lost+found, since files
lose their names when fsck puts them there.
e. Have built-in defaults so that if rpmrc isn't
found, rpm will still run on systems that have
not changed anything in rpmrc. Lacking rpmrc
can arise after partial disk corruption, hacker
activity, or major operator error.
f. Make the rescue disk work with rpm --root /mnt.
Currently it doesn't find rpmrc.
I'm preserving these suggestions by resolbing to a REMIND state.
1) has long since been implemented
2) is not desirable
3) why not just go there? or use ordinary shell expansion
4) should also be present (ghost it)
5) use "--root"
6) other tools can do it, or you can use rpm2cpio
7) tried -Va for verifying? restoring rpms if verification is out of the scope
>1) has long since been implemented
Yes. Thanks! This bug was opened in December of 1998, and it didn't exist
>2) is not desirable
I'm shocked that you say so. I can't count the times I have had to explain to
non-gurus that they have to do things after they run RPM on some packages like
the kernel. The universal answer is, "what? I thought it just worked", and
some disparaging comments on Unix. There are sometimes good reasons why the
user should do things manually, but you *must* tell them! Comments on web pages
aren't enough because RPMs get handed around as-is. There are plenty of other
diagnostics that can get printed, so such a message would not be out of line
with the existing behavior of RPM. The amount of effort to add an echo to the
postinstall script to the kernel is less than that required to reply to this
message, and it's the right thing to do.
>3) why not just go there? or use ordinary shell expansion
First, a path would take the first occurrence only, so you could set it to
.../i686:.../i386:... and only try to install one kernel. Second, command lines
of that sort can get very complex. I'm trying to make things easier for the
user. This would not be a hard option to implement.
>4) should also be present (ghost it)
Sorry, I don't understand your response. "Ghost it"? If it's now implemented,
thanks. But I don't see anything in the man page.
>5) use "--root"
No, that expects to find an rpm database. What I was looking for and didn't
rpm2cpio whatever.rpm | cpio -i
I think this command (and the fact that rpms are thinly-disguised cpio archives)
should be mentionned in a sentence or two on the man page. I know it's in the
see-also list but that's not very visible.
>6) other tools can do it, or you can use rpm2cpio
Yup, didn't know about it when I entered this bug. It would be good to
advertise rpm2cpio more prominently on the man page.
>7) tried -Va for verifying? restoring rpms if verification is out of the scope
> of rpm
Yes I have tried it. The output is voluminous even on a newly-installed system,
and you have to be an expert to know which files are ok to have change and which
This is the most important of the suggestions I made 22 months ago, and the only
one that isn't either implemented or feasible to do other ways. Linux, and
especially Red Hat's version, is very susceptible to formulaic breakin just
because it is open-source and widespread (and despite the high quality of the
code itself). More and better tools to clean up and recover from hacking
activity are badly needed. The same goes for crash recovery (though I hope ext3
helps us out there). It's certainly within scope for rpm to do the verify job
better and at least to provide a list of packages with suspect files.
7a is hard to do manually unless you know every log and config file in Red Hat
7b could be done with some shell script-type coding, but it's so easy it should
just be a feature.
7c is very close to rpm -F, except that instead of updating a package if it has
a newer version,
it updates the package if it's corrupt. Given that rpm -V and rpm -F both
exist, I don't see this as much of a stretch to the scope of RPM. It
essentially combines the two intelligently. At least produce a list of
7d is *only* possible with RPM, since RPM has the database of md5sums.
7e easy and sensible, since 99.9% of all systems have the default rpmrc. If
your rpmrc gets blown away in a disk crash, you're in sorry shape.
7f may be obsolete, but please check for each release.
You may think that this is a long laundry-list of obscure suggestions that would
never find a use in real life. They aren't. I wrote this bug report when I was
on a research trip for 2 weeks in the Chilean Andes. My Red Hat Linux laptop
was crucial to my work there, but I had regular crashes due to bugs in an
ethernet driver. We had no internet and no telephone, and there I was in the
middle of the night at 18,000 feet trying to do a system recovery after a
particularly heinous fsck session so I could get some data crunched. Afterward,
instead of flaming about how painful the experience was and how badly
susceptible ext2 (and almost all earlier filesystems for Unix) is to kernel
crashes or power loss, I sat down and asked, what specific tools would have
saved me significant time in this recovery? I think that if I had had the
capability I described above, either in the rpm program or another that used the
same database, I could have turned a recovery effort that took nearly 6 hours
into a matter of a half-hour or less.
Since then, I have kept my systems at work within a few weeks of current
updates, but I have still been broken into twice. On one of those occasions,
the cracker deleted and altered system files. The same tools described above
would have saved me several hours of restoring backups and diffing them with the
Linux isn't a toy anymore. Red Hat knows that and it is moving to fill in the
gaps. In the area of system recovery, however, there are almost no tools
available except rpm and fsck, and in its current incarnation rpm falls short.
I hope you'll consider either adding the features above or producing a new tool
that has them. Compared to the effort to produce RPM in the first place, I
don't think most of these features are that hard to do. If some of them are
done in 7.0, thanks in advance.
I have changed the severity of this bug to "enhancement" (which didn't exist
when I first filed the report), and have updated the version. Please don't
close it until these issues have actually been resolved.
I find many of the suggestions here pretty valuble, but they are mostly
unrelated and it does not make sense to have all of them in a single bug report.
IMHO, this bug should be closed and new bugs should be files *separately* for
each of the suggestions that have not been fixed in the recent versions of RPM.
jhmail, would you consider this?
While filing these separate bugs, I would suggest the following:
- "2" should be filed as an RFE agains the kernel package, not rpm since it can
be easily fixed by adding an appropriate command to the postinstall script.
- "7" should be filed as a bug against all the packages they produce non-empty
"rpm -V" output (for non-config files) without a good reason (recent versions of
RPM allow one to specify what aspects of a file should be checkeg during -V).
This way we can turn "rpm -Va" into something truly useful.
P.S. My personal solution to "7" - I have a cron script that runs "rpm -Va" and
e-mails me whenever the output changes. This way I will be aware of unexpected
changes and, also, when something goes wrong, I can always run "rpm -Va" and
compare the output with the output I have saved from the last two cron jobs.
Would it be a good idea to supply such a script with the rpm package? May be at
least as contrib and not active by default?
[root@groucho Dumper]# rpm -q --whatrequires Canna-libs
no package requires Canna-libs
[root@groucho Dumper]# rpm -e Canna-libs
error: removing these packages would break dependencies:
libcanna.so.1.0 is needed by xemacs-21.1.14-23.7.2
libRKC.so.1.0 is needed by xemacs-21.1.14-23.7.2
[root@groucho Dumper]# rpm -q --whatrequires libcanna.so
no package requires libcanna.so
[root@groucho Dumper]# rpm -q --whatrequires libcanna.so.1
no package requires libcanna.so.1
[root@groucho Dumper]# rpm -q --whatrequires libcanna
no package requires libcanna
[root@groucho Dumper]# rpm -q --whatrequires libcanna.so.1.0
it seems that rpm knows the connection between Canna-libs and libcanna.so,
it could be more helpful on --whatrequires. yes its imprecision by user, but
rpm knows that the command, narrowly interpreted, fails, and could re-construct
some alternate command-lines, and re-run. (not how you'd actually do it)
how about single-letter aliases
--whatprovides => -qg (ie --whatgives)
--whatrequires => -qn (ie --whatneeds)
how about some new dependency types, (gleaned from enigma-list)
current: X needs Y
add: X needs-one-of Y,Z
then Y,Z could be language specific, and we wouldnt need japanese support
for english users.
further, if Z is empty, but satisfies dependency, you get
--whatwoulduseifavailable, assuming ordered application of list.
since you dont want to break existing scripts, perhaps some of this should be
enabled by -H aka --helplusers (youre already case sensitive, -v != -V)
The dependancy is on libcanna.so.1.0, not on the package that that lib is
in. So it is possible that the name of the package that provides that
library may change in the future.
This is a really old bug covering multiple items.
As discussed in the bug many of these things are implemented in rpm, others can
be handled by using a depsolver such as yum.
If there are specific items you feel need to be addressed still in rpm 4.4.x
please test on Fedora Core 4 and file new RFE's for those items.