GSoC Project: Final Report

Shashwat Pandey devshashwatpandey at gmail.com
Thu Aug 21 13:37:41 PDT 2014


Thank you for your feedback.

To me it would make more sense to offer three options:
> - yes (continue and leave those dependencies in a broken state)
> - no (stop)
> - continue and recursively uninstall all dependencies
>
> Offering a third option like --follow-dependencies or --follow-dependents
in such cases is a nice idea. To display the question with three choices we
can either use the ui_ask_singlechoice proc from the API(line 5431 in
src/port/port.tcl) {easier way} or add an extra option to the ui_ask_yesno
proc (line 5364) {harder way} for such questions by using the 'name'
parameter. The singlechoice way will number the choices which will not look
pretty.


> While you covered this with "--follow-dependencies", it feels more
> natural to be able to pick the third option here. Or at least the
> output should document that additional option (which should be trivial
> to patch at least).
>
To implement this src/registry 2.0/portuninstall.tcl and src/registry
2.0/registry_util.tcl need to be patched.
I will patch the output to document the --follow-dependents option soon.


> (Another "problem" that I'm often experiencing is that I'm unable to
> uninstall a port when *inactive* ports depend on it. Sometimes
> macports should distinguish between the two and make less headaches
> when inactive ports get broken.)
>
Thanks for pointing out another use case. I will add this to the wiki page
where I am maintaining a list of all the implemented and not yet
implemented use cases here
<http://trac.macports.org/wiki/SummerOfCode2014_interactive>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140821/3e25a1cf/attachment.html>


More information about the macports-dev mailing list