On Sun, Apr 19, 2020 at 04:36:48PM +0200, Ingo Schwarze wrote: > All this is kind of typical for the pkg tools: one question typically > allows several different answers. There typically isn't one single, > canonical way of doing something. There typically isn't one unified > output format, but several different ways to represent information > in the output. Part of that is due to the unavoidable complexity > of the system. Other parts may be influenced by the fact that > espie@ is not tedu@.
I don't think tedu would do much better... or we would have a ports tree with only the 100 ports he's using, and nothing more. There are some unavoidable complexities to the sheer size of the tree, and the necessities of updates not to fail... ... plus the fact that the ports tree needs to stay somewhat "entry-level". Actually, not having recursive depends easily available on an installed package base is somewhat tedu-ish. Most specifically, it's not very useful for anything in common usage. What would you want it for ?... sure it's nice information, but in practice, unused dependencies from former ports get gc'd with pkg_delete -a... ... and if you're actually tinkering with dependencies, it's generally related to the ports tree proper, and there is a plethora of targets in there... along with indeed, sqlports which can give you all the info that you need, assuming a bit of sql magic. Once you understand, show-reverse-deps, it's fairly easy to write customized stuff that does similar things. BTW, any supplementary tool that does similar things directly in shell has exactly zero chance to be included in the distribution. The offical parser for PackingList *is* the perl code, dependency handling as well. Anything else is very likely to miss special cases and break atrociously.
