Bug 536

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
/foo/bar/{xyzzy,magic}*rpm 
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

>1) has long since been implemented

Yes.  Thanks!  This bug was opened in December of 1998, and it didn't exist
then.
 
>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
aren't.

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
Linux.
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.

--jh--

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
xemacs-21.1.14-23.7.2

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.