[pacman-dev] pacman -S 'dependency>=2.0' (was: Status of _alpm_find_first_satisfier?)

[Nagy Gabor]

> On Wed, Jul 2, 2008 at 12:48 PM, Nagy Gabor <ngaba at bibl.u-szeged.hu>
> wrote:
> >
> > I think that _alpm_find_first_satisfier implementation is a bit
> > complicated... I would prefer just ~reimplement
> > _alpm_find_dep_satisfiers instead of calling it (and introducing a
> > new "wrapper").
> >
> 
> I don't understand what you mean here, but feel free to take that
> patch, and rework it as you wish, then re-submit it on the ML.
> 
There is no "real" problem with it (however, in my "programming taste"
this implementation is a bit overkill;-), I've just tried to figure out
why this hasn't been accepted yet.

I did a little investigation, where find_dep_satisfier (which
finds _all_ satisfier) is used: in find_pkg_satisfier, which is the
replacement of what_provides. As I noted earlier, using
find_pkg_satisfier instead of what_provides automatically enabled
pacman -S 'dependency>=2.0', which is very useful imho: You can use
this feature as dependency resolving in a script (e.g. makepkg).
However, this cannot be documented yet (it is a super hidden
feature ;-), because of a little edge case: The "literal first" rule
doesn't work (versioned provision can be the first satisfier here).
That's why I planned to share the "find literal, then find
satisfier" part of resolvedeps  between front-end and back-end. (In
this case we need find_first_satisfier only, so find_dep_satisfier can
be modified to do this).
Now I ran into a problem: The front-end search for _all_ providers
(satisfiers), and will stop if more than one was found. This is not
compatible with resolvedeps behavior... So if we want to keep this, we
cannot share the code (but can re-implement first literal, then
satisfier). Or I can refer to the TODO in resolvedeps code: what to do
in case of multiple provision?
So my question: what do you think about this pacman -S 'dep>=2.0' idea,
and if you like it, which implementation do you prefer?

Bye