Recursive dependencies, recursive uninstall, variants

Rainer Müller raimue at macports.org
Mon Apr 28 03:07:29 PDT 2008


Shreevatsa R wrote:
> On Sat, Apr 26, 2008 at 04:20:13PM +0200, =?ISO-8859-1?Q?Rainer_M=FCller_ wrote:
>> Shreevatsa R wrote:
>>> Hi MacPorts developers,
>> Hi,
>>
>> 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...
> 
> That's what I was using the global variable $shownports for -- to avoid
> displaying, and recursing on, portD after the first time.

Which is a bit unexpected. At least we should mark this port because the 
real tree is already in the output above. Otherwise one could read this 
as "portD has no dependencies".

>>> 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).

[snip]

>> I don't quite understand why you call uninstalling ports a "real pain". 
>> What is the problem with that?
> 
> ~$ port uninstall portA
> ---> Unable to portA, the following ports depend on it:
> --->   portB
> --->   portC
> --->   portD
> --->   portE
> --->   portF
> --->   portG
> --->   portH
> Error: port uninstall failed: Please uninstall the ports that depend on portA first.

This already got better in trunk, port uninstall --follow-dependents is 
possible.

> [Copy-and-paste the names one-by-one...]
> ~$ port uninstall portB portC portD portE portF portG portH portA
> ---> Uninstalling portB
> ---> Unable to uninstall portC, the following ports depend on it:
> --->   portD (etc.)

Oh yes, the topological sort is missing here which should be done 
automatically.

> [WTF? It's right there in the list, why can't you figure it out?]
> [Swap portC and portD]
> ~$ port uninstall portB portD portC portE portF portG portH portA
> Error: port uninstall failed: Registry error: portB not registered as installed.
> [Aaargh.]
> [Repeat many times.]
>  
> Am I doing it incorrectly?
> 
> Now, if `port dag --dept-list portA` were guaranteed to return a list of all installed
> dependents of portA in topologically sorted order, then 
> `port uninstall $(port dag --dept-list portA)` would Just Work. (Of course, I
> don't care about the syntax, it could be `port uninstall --follow-deps portA`,
> all I mean is that a reusable function for dependencies or dependents would be
> useful.)

No need for an extra function, just sort the list for port uninstall in 
topological order before beginning to uninstall. The real problem here 
is the implementation which just uses foreachport in the given order 
from the command line.

And maybe don't error out completely if a port is not installed...

> Here is some code; consider it proof-of-concept. It would be good if someone
> can tell me what changes to make and what to do to get it committed.
> 
> This is how it works now (I'm using "dep" for dependencies and "dept" for
> dependents.)
 >
> ~$ port dag --dep-list glib2
> glib2 pkgconfig gettext expat libiconv ncurses gperf ncursesw

So why a new target again...? We already have `port deps' and `port 
dependents' and these two should be improved instead of rewritten with a 
new name.

[Did not have time to try the code yet].

Rainer


More information about the macports-dev mailing list