MySQL Bugs: #43133: If upgrade from 5.0.66 to 5.0.72 upgrade fails, but yum returns it completes

Bug #43133	If upgrade from 5.0.66 to 5.0.72 upgrade fails, but yum returns it completes
Submitted:	24 Feb 2009 10:10	Modified:	29 Jun 2010 11:20
Reporter:	Sveta Smirnova	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Packaging	Severity:	S3 (Non-critical)
Version:	5.0.72	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
Upgrade from 5.0.66 to 5.0.72 fails due to bug #42953

But if one uses yum it returns upgrade completes, although nothing upgraded.

How to repeat:
  	 We have a RHN-Satellite Server here where we fetch our MySQL-Enterprise Packages and resign them with our private key (only resign, no change of the package itself). When I tried to install the update of the server, we encountered two problems

First, the 5.0.72 package claims to be from a different vendor - are there any significant changes? Since it claims that I have to remove (manually) the old package instead of upgrade.

Second: the 5.0.72-package itself has a minor bug: the scriptlet failes with exit status 1, but this exitcode doesn't get transported back to the package manager. The Package Manager thinks that the update was successfull:

[root@dbserver ~]# yum update MySQL-server-enterprise-gpl.x86_64
Loaded plugins: rhnplugin, security
[..]
Skipping security plugin, no data
--> Running transaction check
---> Package MySQL-server-enterprise-gpl.x75_75 0:5.0.72sp1-0.rhel5 set to be updated
--> Finished Dependency Resolution
[..]
Downloading Packages:
MySQL-server-enterprise-gpl-5.0.72sp1-0.rhel5.x86_64.rpm | 18 MB 00:00
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction

****************************
A MySQL server package (MySQL-server-enterprise-gpl-5.0.66sp1-0.rhel5) is installed

The current MySQL server package is provided by a different
vendor (MySQL AB) than Sun Microsystems, Inc.. Some files ma be installed
to different locations, including log files and the service
[..]

error: %pre(MySQL-server-enterprise-gpl-5.0.72sp1-0.rhel5.x86_64) scriptlet failed, exit status 1
error: install: %pre scriptlet failed (2), skipping MySQL-server-enterprise-gpl-5.0.72sp1-0.rhel5

Updated: MySQL-server-enterprise-gpl.x86_64 0:5.0.72sp1-0.rhel5
Complete!

[root@dbserver ~]# echo $?
0

Suggested fix:
Return error from scriptlet to yum, so it can detect the failure.

With RPM it fails fine.

The base issue is "yum" not reacting to the failure of a "%pre" script which is contained in our RPM and fails on intention.
(Yes, it was silly to fail in this case, but there may come other cases where it is correct to fail.)

I don't see what we can do here, to me this is a bug in "yum":

1) Your report quotes that the scriptlet exited non-zero:
error: %pre(MySQL-server-enterprise-gpl-5.0.72sp1-0.rhel5.x86_64) scriptlet failed, exit status 1
error: install: %pre scriptlet failed (2), skipping
MySQL-server-enterprise-gpl-5.0.72sp1-0.rhel5

2) You report later:
"With RPM it fails fine."

Trying Google to find information about "yum" handling installation problems, I got plenty of results, the most significant one for this problem seems to be:
http://www.bluequartz.us/phpBB2/viewtopic.php?t=74694&sid=67f2c7226a8125aa4c06133913f5abbc

It points to "yum" bug 427866, whose mails I found here:
https://bugzilla.redhat.com/show_bug.cgi?id=427866

Please check those texts, I found comment#4 with this quote:
|  Aborting the transaction on problems is basically
|  just as bad as continuing,
|  you'll end up with an inconsistent system anyhow.

Also note comment#8:
|  Grab exit code from rpm transaction
|  The attached patch makes yum emit a warning if some errors
|  occurred during the transaction. The exit codes from ts.run()
|  of current bindings are "creative" but at least yum will warn
|  you instead of happily saying "Complete!" if something went
|  belly-up while in transaction. Feel free to tune the exact
|  message to your liking...

If this is still yum's current position, I consider this "broken by design", but see no way to fix this.

For now, I put this bug to "need feedback" to give you a chance to comment.
If you find some information that we can force "yum" to really exit with an error, please tell me.
If we don't find any such hint, this must be closed as "not a bug".

Aside:
Bug#42953, which caused this trouble, is now treated as a duplicate of bug#45534, and that is fixed, so this specific cause shouldn't happen in the future.

Hmm - setting it to "need feedback" got lost Friday, doing it now.

My position is still to consider this a "yum" bug.