Remarks on the --optional feature of pactree

Daniel M. Capella polyzen at
Fri Jul 31 01:40:36 UTC 2020

On Thu Jul 30, 2020 at 7:40 PM EDT, Sebastian Jakubiak wrote:
> Hello,
> I would like to share my thoughts on how `pactree --optional` works.
> First thing: shouldn't it omit uninstalled optional dependencies when
> asked to query the local database (no -s/--sync)? There was a comment by
> Johannes Löthberg on an earlier attempt to implement --optional:
> > The problem is that while it works fine for -so, when searching for
> > local packages it should properly exclude optional dependencies that are
> > not installed so they're not printed, rather than being printed as
> > unresolvable.
> (source:

Vaguely recalled there being history to look into, but it slipped my

> So for example here:
> $ pactree -d1 -o python2-urllib3
> python2-urllib3
> ├─python2
> ├─python2-pysocks: SOCKS support [unresolvable] (optional)
> └─python2-pyopenssl provides python2-pyopenssl: security support
> (optional)
> python2-pysocks should be skipped, shouldn't it?

Since the installed package already has the optdep information, I think
the dependency tree should show these, listed as `[uninstalled]`.

> Second: default value of DEPTH (optional argument of -o/--optional). I
> think that infinity (-1) would have been a better choice than 1. In
> other words, no depth specified should mean no depth limiting. The
> function of the switch could then be described like so:
> --optional[=DEPTH] also list optional dependencies, optionally
> stopping at DEPTH
> This would be kind of analogous to how 'normal' depth works -- unlimited
> unless --depth=N is passed. Also, it may sound silly but -o1 feels
> slightly easier to type if need be / looks less strange than -o-1.

Perhaps this was done to avoid flooding? As an extreme example:
~ > pactree -so-1 diffoscope | wc -l

Albeit confusing, I think I like this behavior.

cc Will

> But I guess that other people's views on this matter might differ from
> mine. Plus, it is maybe too late anyway to change the behavior of the
> feature since a release containing it has been made. I should have
> raised my concerns earlier.

Not too late IMO.

Daniel <>

More information about the pacman-contrib mailing list