On 3/18/07, Jeremy Katz <[EMAIL PROTECTED]> wrote:
The thing about rpmlib() requires is that you really _can't_ do anything about them. Either -- a) you have the rpmlib capability already provided with your current version of rpm; this means that checking it doesn't really buy you much or b) you _don't_ have the rpmlib capability. Installing a new rpm at the same time isn't going to help as the rpmlib capability is required at install time. You instead have to do it ahead of time, in a separate transaction and then restart yum entirely. And hope the new version of rpm doesn't depend on something else which depends on a new rpmlib capability. So _solving_ the dep isn't really all that useful... and we end up doing a final transaction check using rpm before ordering and performing the installation which will barf if there's an unsatisfied rpmlib() dep, so trying to handle what we know we can't is just a bit of a waste.
So will yum be able to handle this case with the skipbroken plugin for example, or does the whole transaction just fail? I'm trying to avoid the issue on some of our older machines with pretty old versions of rpmlib that had locking issues with concurrent db access. If I placed a package with a rpmlib() requirement into a repo with a machine that didn't meet the requirement will it always fail the entire transaction or is there a way to prevent that. I've confirmed that the rpms will install on a systems that do have the requirements through yum so I think I'm probably good since its such a small number of machines that might trip this condition. As an academic question, should we solve those deps in the case where a new rpmlib() requirement is introduced in the future? That's probably a bridge better crossed when we get there. Thanks for the detailed answer guys! Russell
_______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
