[Yum-devel] Does the yum depsolver correctly resolve rpmlib(foo) virtual capabilities

[Russell Harrison]

On 3/18/07, Jeremy Katz <katzj at redhat.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.baseurl.org/pipermail/yum-devel/attachments/20070319/23823881/attachment.htm