Bug 454556
Summary: | rpm transaction continues when it shouldn't | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Mustafa Jamil <mustafa_jamil> |
Component: | rpm | Assignee: | Panu Matilainen <pmatilai> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 5.2 | ||
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-10-02 12:55:10 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
Mustafa Jamil
2008-07-08 22:04:15 UTC
Panu, when you comment on this bug, can you please explicitly clarify whether this is a bug in upstream code, or just in the Redhat/Fedora codebase? I have co-workers who have given me unconfirmed reports that this happens on SLES 10 SP 2 as well (so it's not just a RedHat bug, I think), but I'm not sure of that. OK, I confirmed myself that this behaviour is reproducible in SLES 10 SP 2. So it's definitely in upstream code. RPM transactions aren't ACID, they're only "best effort" and only guarantees that there are no known problems before transaction starts. It's impossible to predict scriptlet failures and it's also impossible to reliably undo the transaction once started as there's no way to undo scriptlet actions that might've occurred up to the point of failure within the transaction. And stopping the transaction on a single package failure is just as (or even more) dangerous as trying to continue. This isn't a bug, just ugly reality of the complexities involved. Panu, this is a classic case of "it's not a bug; it's a feature." I'm not trying to be rude, so please don't take my comment that way. I understand the limitation that you're pointing out, but there seem to be various ways that it can be addressed (spec file authors, for example, can be required to provide arbitrary rollback code for each scriptlet; while that wouldn't guarantee true ACID rollback, it certainly is a far better attempt at attempting to do the correct thing rather than the fire-and-forget model rpm currently has). But what I'm hearing is that this simply won't get addressed. Is my understanding correct? Is there a better approach to this (or a chance to address it) in rpm5, at least? Panu, furthermore, in this specific case, I'd be happy if the dependency checking was performed once again right before an rpm is installed (even in the middle of a transaction). That seems very doable to me. In the example I provided, A-dependent set a PreReq dependency on A. Right before A-dependent is actually installed, why can't its Requires and PreReq's be checked once again? I can see that being performance-unfriendly, so why can't it be added as an option to rpm (e.g., --recheck-dependencies)? Let me rephrase: intelligently skipping installation of packages whose dependencies failed to install inside the transaction is quite different from aborting (and attempting to roll back) the transaction, and is quite feasible to some extent at least. Addressing this is beyond the realm of RHEL 5 however -> WONTFIX. This needs to be tracked upstream at rpm.org. |