I was instaling yesterday's Raw Hide updates via "up2date -u" and it died: ... 21:kudzu ########################################### [100%] 22:tk ########################################### [100%] There was a fatal RPM install error. The message was: There was a rpm unpack error installing the package: tk-8.4.5-5 After that, it turned out that the first 21 packages were upgraded correctly, but the remaining ones (started with tk) were simply erased.
Created attachment 98453 [details] Full output of that up2date session.
Turnes out that the packages were still there _on disk_ (not sure whether that were old ones or new ones), but were missing in the RPM database. So this is very similar to bug 115182.
rpm unpackage errors typically indicate a packaging issue that causes the cpio payload format to break (replacing dirs with symlinks is a common one). So reassigning to tk
The tk error (which was already fixed AFAIK) is not what the bug is about. Even when there is indeed "a packaging issue that causes the cpio payload format to break", IMHO up2date should handle it much better. Dropping packages _that are still installed_ from the db is not just a big annoyance, it's also a security problem.
This was fixed in tk-8.4.5-6. *** This bug has been marked as a duplicate of 118030 ***
Sorry, Aleksey, I didn't read comment 4 properly: reopening.
the transaction behaviour in lieu of bad packages like that tk package is an rpm issue, reassigning there.
The above scenario is the only behavior possible for up2date because there is no way to resume the current transaction from an error callback from rpmlib. AFAICT, the root cause of the problem was bad packaging. Fixing the package is the correct approach. Graceful exit under all possible error conditions, including bad input from packages, etc., is not going to happen soon, if ever.
> there is no way to resume the current > transaction from an error callback from rpmlib. I completely agree. However there is a major problem with the way the error is currently handled - the error message only talks about the _new_ package failing to unpack, but the _old_ package also ends up silently disappearing from the db! This bug does not request for up2date to be able to magically recover from this error (that, of course, would be unreasonable), it just asks for it to leave the db in consistent state (or at least in a state would not add a potential security problem - see below) before bailing out - it needs to retain the record that _some_ version of the package is still installed. To reiterate, the problem with the current behaviour is that there is no record left that the old package is still there --- and because of it even after the packaging issue is fixed, the old package will not be updraded without manual intervention. And, of course, leaving old bytes on the disk (without any record of that in the rpm database) could be a security risk (hence "severity: security"). TIA for reconsidering the deferral.
Changing severity to "normal", red "security" text hurts my eyes.
*** Bug 115182 has been marked as a duplicate of this bug. ***
The root cause of #115182 is that up2date-gnome crashed, not up2date. The general problem has been addressed in rpm upstream with auto-rollback. Packages in a partially installed transaction are automatically replaced, leaving the rpmdb in the inital state. UPSTREAM. segfaults need to be fixed in the programs that are segfaulting, which is up2date and up2date-gnome, not rpm.
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
If aborting from middle of transaction (well, callback) hurts, don't do it then is also one possible answer... This is pretty up2date-specific and up2date isn't in Fedora anymore, closing.