Bug 536 - Suggestions to improve RPM
Summary: Suggestions to improve RPM
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 7.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1998-12-19 00:50 UTC by Joe Harrington
Modified: 2007-04-18 16:22 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2005-06-06 21:43:41 UTC

Attachments (Terms of Use)

Description Joe Harrington 1998-12-19 00:50:59 UTC
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
   crash/hacker recoveries:

	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`)
	    	echo $i
	    	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.

Comment 1 Jeff Johnson 1999-09-02 16:52:59 UTC
I'm preserving these suggestions by resolbing to a REMIND state.

Comment 2 Trond Eivind Glomsrxd 2000-10-04 22:11:57 UTC
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
of rpm

Comment 3 Joe Harrington 2000-10-04 23:43:28 UTC
>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
> /foo/bar/{xyzzy,magic}*rpm 

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
find was
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
corrupt packages.
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
running system.

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.


Comment 4 Aleksey Nogin 2001-08-16 20:39:53 UTC
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?

Comment 5 Need Real Name 2001-12-05 00:33:15 UTC
[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)

Comment 6 Mike A. Harris 2001-12-19 09:45:20 UTC
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.

Comment 7 Paul Nasrat 2005-06-06 21:43:41 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.