[pacman-dev] Another idea

Bryan Ischo bji-keyword-pacman.3644cb at www.ischo.com
Thu Jan 15 17:12:11 EST 2009


Xavier wrote:
> On Thu, Jan 15, 2009 at 10:08 PM, Nagy Gabor <ngaba at bibl.u-szeged.hu> wrote:
>   
>>> Hey all.  I've been thinking about my patches and the concerns that
>>> list members have had about them and I've come up with a different
>>> way of accomplishing the same thing that may be more palatable:
>>>
>>> - Modify the signature of deps.c:_alpm_resolvedeps so that it takes,
>>> instead of a list of packages to resolve, a single package.  It would
>>> return 0 if the resolve succeeded, 1 if the resolve failed, and would
>>> additionally return a list of dependencies that this package needs
>>> for this sync.  In the parlance of _alpm_resolvedeps, it would return
>>> the 'pulled' list.  _alpm_resolvedeps would, just as it does now,
>>> fail immediately when it encountered an unresolvable dependency, and
>>> would not require the graph structure to keep track of dependents.
>>> It would be a much simpler change to _alpm_resolvedeps.
>>>       
>> This is a good idea imho.
>>
>>     
>
> It sounds good, but isn't it a bit a step backward after this :
> http://projects.archlinux.org/?p=pacman.git;a=commit;h=72c0ab5c51d5119b6f81c768b1a0f6ff499df292
> However, we were not considering this new behavior in case of
> unresolvable dependency back then.

I will have to let Nagy comment on this, as I have read but do not 
really understand the change you are referring to.  It looks to me like 
a big part of his change was factoring out some logic from 
_alpm_resolvedeps into a separate function (_alpm_resolvedep).  What I 
am proposing does not conflict with this idea, the structure of the 
functions as they are is still appropriate after my change.  He also 
seems to have fixed some bugs that were due to resolved dependencies not 
being re-used to satisfy further resolves (I think).

But Nagy should give his own thoughts as he understands his change much 
much better than I do.

Thanks,
Bryan



More information about the pacman-dev mailing list