[pacman-dev] Status of _alpm_find_first_satisfier?
Hi! I would like to ask you about this patch: http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=commit;h=aae0f... * I'd like to refactor resolvedeps, and this function would be useful there. (I think *list param can be input/output list of resolvedeps like in recursedeps (and kill syncpkg param), and "find_literal" "find_othersatisfier" parts can be moved to its own function and used by front-end too...) * Xavier says that this patch "Address two concerns". One of them is the memleak caused by current _alpm_find_dep_satisfiers usage (which returns with a list, but we don't free it), which needs to be fixed even if this patch will be rejected. 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"). Bye
On Wed, Jul 2, 2008 at 12:48 PM, Nagy Gabor <ngaba@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.
On Wed, Jul 2, 2008 at 12:48 PM, Nagy Gabor <ngaba@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
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). To be more precise, we can share it, but we shouldn't do it because of some unwanted slow-down.
On Wed, Jul 2, 2008 at 2:30 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
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...
Maybe you can just drop this behavior for now, because this is indeed inconsistent with resolvedeps. Then if we want to reintroduce some kind of handling of multiple satisfiers in the future, it should be done for both explicit targets (which is currently done in frontend) and dependency resolving (in backend).
Maybe you can just drop this behavior for now, because this is indeed inconsistent with resolvedeps. Then if we want to reintroduce some kind of handling of multiple satisfiers in the future, it should be done for both explicit targets (which is currently done in frontend) and dependency resolving (in backend).
I've just found the following: '/' handling is done in backend (sync_addtarget), so pacman -S db/sh won't do the expected operation, because the provision handling is done in front-end. Is this OK? Bye
participants (2)
-
Nagy Gabor
-
Xavier