Recursive dependencies, recursive uninstall, variants
Rainer Müller
raimue at macports.org
Sat Apr 26 07:20:13 PDT 2008
Shreevatsa R wrote:
> Hi MacPorts developers,
Hi,
> I was planning to write some non-trivial code before posting to this
> list, but I thought I would first check if I was doing anything
> stupid.
[snip]
> So deciding that at least knowing all dependencies of a port
> beforehand would help, I tried writing a command for recursive
> dependencies. The proc action_deps does a lot of stuff, and it's not
> easy getting just the list of dependencies with no extra output, so I
> wrote my own "bare" proc that does the actual dependencies, etc., and
> rdeps that recursively calls it:
Yes, a --pretend feature is on the wish-list since a long time and would
be really nice to have.
[snip]
> And "rdeps action_rdeps" in action_array. Yeah, it uses a global
> variable to avoid printing the same ports again, but it works:
>
> ~$ port rdeps subversion
> expat
> neon
> gettext
> libiconv
> gperf
> ncurses
> ncursesw
> openssl
> zlib
> apr
> apr-util
> db44
> sqlite3
> gawk
> gmake
> readline
This looks good. Of course the output could be a lot better... And how
are you dealing with ports appearing multiple times? E.g. portA depends
on portB and portC, and these two depend on portD. If portD depends on a
lot of other ports you get a long list - twice. Don't know if that can
be improved in the ascii output...
But I don't like introducing a new command just for this. This should be
port deps --follow-deps as discussed earlier.
What I also would like (and I think Ryan would like it, too ;-)) is the
possibility to output the dependency tree in the dot language for
graphviz. So we could use something like this to get a nice graph:
port deps --follow-deps --dot | dot -o depgraph.png
Would also be cool to have such graphs on the website.
> This is not great code, but it does what I want. (It is also the only
> Tcl I have ever written, so please tell me what I'm doing stupidly.)
> I was planning to do the same for variants (because I install
> something and later discover I should have installed one of its
> dependencies with a different variant), and for uninstall (because it
> is a real pain to uninstall ports).
Not sure what a mean with "variants". port deps currently does not take
dependencies into account, because it is reading the PortIndex only.
This makes it probably faster but this feature is missing. So to solve
this one would have to [mportopen] all ports and their dependencies to
get the dependencies list modified by variants.
I don't quite understand why you call uninstalling ports a "real pain".
What is the problem with that?
> More specifically, I was planning to
> (1) make a general (simple) function for getting a specific port's
> "tree of dependencies" (and/or tree of dependents) and then something
> to act on it. Uninstall would then be trivial.
> (2) Also, putting something to return the list of dependencies of a
> port in the MacPorts API itself.
> (3) Also, looking at action_deps, it seems to share a lot in common
> with other functions (searching for ports, etc.), so that part can be
> cleaned up...
Sounds like a good plan!
Rainer
More information about the macports-dev
mailing list