Bug 20286

Summary:	RPM has cryptic and non standard error messages
Product:	[Retired] Red Hat Linux	Reporter:	kestes
Component:	rpm	Assignee:	Jeff Johnson <jbj>
Status:	CLOSED RAWHIDE	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	asundell+rhbz, dr
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-06-05 18:29:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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
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
directory
) = 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.