Bug 20286 - RPM has cryptic and non standard error messages
Summary: RPM has cryptic and non standard error messages
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 7.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2000-11-03 16:08 UTC by kestes
Modified: 2007-04-18 16:29 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2002-06-05 18:29:56 UTC

Attachments (Terms of Use)

Description kestes 2000-11-03 16:08:07 UTC
this bug is similar to bug: 2895 but this one is MINE, and has more detail,
and additional requests.

First I would like the RPM error messages to be of a standard format
and tell which executable (rpm) has triggered the error. My build
process is quite complex with manny levels of scripts running other
scripts and I can not tell where the errors originate if the executable
does not identfy itself.  I have spent many a time running strings over
executables looking to see which binary could have given me a particular
error message.  It is also important that if RPM runs a program which 
fails (like a dependency program or a build script) that RPM should throw
its own error message into the STDERR so that I can track down the error
to RPM and its children.  I may not know that 'find-requires' is a child
of RPM so if I see an error from 'find-requires' I need to narrow this
down to an RPM error.  This is verry necessary for any automated build
monitoring system, like tinderbox.  The system needs to have regular
 expressions to determine what 'build errors' look like.  Currently there
is no regular expression which can capture what an RPM error looks like.

Second (this is like an earlier bug) the RPM errors are too cryptic.
A bigger effort should be made to narrow causes of failure down to
 something a programmer can understand and give meaningful messages.
I often have to add a substatial ammount of checking code in my 
executables, beyond what is strictly necessary to complete the job,
 to ensure that all errors are meaningful to the user.  Each program
action needs to have guards to check before the action is taken that it
is likely to succeed.  All of the common error causes should be
explicitly checked for and notifiy the user with a clear error message.

Comment 1 Alan Sundell 2002-06-05 18:29:51 UTC
As a specific and supporting example of this bug (on RedHat 7.3/rpm-4.0.4):

# ls nss_db.spec
# rpm -bp nss_db.spec 
nss_db.spec: No such file or directory

...when what really happens is:

# strace rpm -bp nss_db.spec
execve("/usr/lib/rpm/rpmb", ["/usr/lib/rpm/rpmb", "-bp", "nss_db.spec"], [/* 20
vars */]) = -1 ENOENT (No such file or directory)
write(2, "nss_db.spec: No such file or dir"..., 39nss_db.spec: No such file or
) = 39
_exit(1)                                = ?

Not only is this error message terse, it is misleading, for it is not
nss_db.spec that does not exist, but rather /usr/lib/rpm/rpmb.  Therefore, at
the very least, it should say:

/usr/lib/rpm/rpmb: No such file or directory

Now, I understand why this error occurred, and, judging by past responses to
bugs in this component, I'll probably get flamed by someone at redhat.com for
suggesting this, but might it not say something like:

rpm: Fatal error: could not exec(/usr/lib/rpm/rpmb): No such file or directory
rpm: Maybe you need to install rpm-devel?

I'm no error-writing expert, so I'm sure the above could be polished up a bit,
but I think that it's fairly reasonable to expect that a program:
1) Give an error that accurately represents what went wrong
2) Clearly identify itself in error messages
3) Clearly identify what it was trying to do when it encountered the error

It also seems wise, for certain errors that occur in well-known conditions, to
give a polite suggestion for a way that the user can fix the problem.

Comment 2 Jeff Johnson 2002-08-07 23:10:22 UTC
Problem #1: the error messages are much more regular now.

Problem #2: the build modes have been moved from
rpm into rpmbuild, and the popt aliases that provided
backward compatibility (somewhat imperfectly) have
been removed as well. Details through "man rpm",
Legacy section.

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