On Tue, Oct 14, 2008 at 5:27 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
This seems more like an issue with dependency resolution than anything else. Assuming this is all based on issues with optdepends, like so: $ pacman -S foobar Optional dependencies for foobar: baz $ pacman -S --asdep baz
What we have here is 'baz' indicated as an orphan, but what we *want* is baz indicated as "Required By" foobar, correct?
If so, then it is just a matter of adding more logic to the optdepends property. That is: a) Split entries on ':', and resolve package names (warn if not found?) b) Use optdepend packages when resolving things like orphans and requiredby lists.
If I understand your qualm right, this would be a better way to handle this.
Hmm. This is a valid point.
OK, I suppose that alpm can parse and handle %OPTDEPENDS% field.
What should we do in the following situation?: User installs foo, which pulls bar as dep, as well. Later he installs baz which has bar as optdepend. At this point (without user interaction) we don't know whether user need bar as optdepend of foo, so it is not clear what to do after "pacman -Rs foo". Without extra bookkeeping, we cannot suspect user needs.
So I suggest some new switch ~--optdepend, which simply means that pacman treats optdepends like real depends. Maybe this can be useful with -S, -Rs, or -Qd.
However, this method is not useful, if you have custom needs. Then some extra bookkeeping is needed (maybe turn some optdepend to real depend in local db during install?).
It'd make more sense to me to NOT descend into optdepends at all when removing. It would be an extra step for the end user (remove packages, check and remove new orphans), but it would simplify the pacman side. To put it more concisely: optdepends should NOT be treated like depends when installing or removing.