[pacman-dev] "explicit dependencies", a compromise between explicit and deps

[Aaron Griffin]

On Tue, Oct 14, 2008 at 5:27 AM, Nagy Gabor <ngaba at 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.