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.

- Modify sync.c:_alpm_sync_prepare so that it calls _alpm_resolvdeps once per package in the transaction, rather than calling _alpm_resolvedeps once with a list of the packages in the transaction as it does now. As _alpm_resolvedeps is called for each package in the transaction, three lists will be built up in _alpm_sync_prepare:

1. The list of transaction packages (i.e. the "top-level" packages) that were successfully resolved.

2. The list of transaction packages (i.e. the "top-level" packages) that were NOT successfully resolved.

3. The list of "pulled" packages that came from _alpm_resolvedeps for each transaction package that was successfully resolved.

After all of the resolution has been done, if the list in (2) is not empty, then these packages are used in the new prompt that asks the user "do you want to ignore these packages for this transaction", and if they say "no", then _alpm_sync_prepare will return a failure status code. If they say "yes", then list (2) will be freed and list (1) and (3) will be used to finish _alpm_sync_prepare as normal (after removing duplicates from (3) as necessary).

The advantage of this approach is that it doesn't require any new data structures or helper functions, and changes _alpm_resolvedeps very little.

The disadvantage of this approach is that it is less efficient at runtime. Each top-level package will be resolved individually, which means that some work will be duplicated (i.e. if top-level A and B depend on C, and C depends on D and E, then in this new scheme, the C-D-E dependencies will be calculated once for A and once for B, whereas before, it was only calculated once for A, and then the results re-used for B). I would only expect this to have a significant perfomance penalty in large transactions (say a pacman -Su where hundreds of packages were being updated), and I'm not sure exactly how "large" the transaction would have to be before the penalty became unreasonable.

First of all, if you investigate a package 5 times, pacman may ask the user 5 times, whether he wants to install a package from IgnorePkg (if we switch to non-interactive implementation, user will see 5 warnings). This is odd. However, if we are tricky, we can almost eliminate this problem imho. (Although we must complicate the code a bit.) If you can *successfully* resolve a target package, you _will_ keep all the pulled targets, so you can push them to the ~resolved_targets list (which should be checked first, when you resolve dependencies!*). In real life, we can resolve all targets ~always. Your described problem would appear around unresolvable targets, which is not a common situation. *Note: We prefer target list over pkgcache during dependency resolving. I mean, if you do "pacman -S mplayer libgl-dri" we will select libgl-dri as a libgl dependency satisfier of mplayer. So if possible you should select a satisfier package from the (explicit and resolved_) target list.

I *think* these are the only two approaches:

1. Use a data structure to track dependents, thus gaining runtime efficiency during the resolve of a list of packages, at the expense of extra complexity in the implementation 2. Use no new data structures, instead iterating over each package in the transaction individually, thus gaining simplicity of implementation, at the expense of runtime efficiency

I have already implemented (1). If the concern about the code complexity outweighs the concern about performance, then I can implement (2) instead.

Please let me know how to proceed. Thanks.

Bryan