[MacPorts] SummerOfCode modified

[Ryan Schmidt]

On May 17, 2014, at 06:29, MacPorts <noreply at macports.org> wrote:

> Page "SummerOfCode" was changed by shasha at macports.org
> Diff URL: <https://trac.macports.org/wiki/SummerOfCode?action=diff&version=240>
> Revision 240
> Comment: added list of interactive cases
> Changes:
> -------8<------8<------8<------8<------8<------8<------8<------8<--------
> Index: SummerOfCode
> =========================================================================
> --- SummerOfCode (version: 239)
> +++ SummerOfCode (version: 240)
> @@ -251,7 +251,22 @@
> 
> Write an interactive command-line tool that can be used instead of the non-interactive port(1). (The existing "interactive mode" of port(1) is actually just batch mode reading from stdin, and is not really interactive.) Factor out code used by both tools into a shared module.
> 
> -An interactive tool would ask for user input to resolve many situations that cause port(1) to simply error out. For example, if you try to install a port and one of its dependencies conflicts with something already installed, it could ask if you want to deactivate the installed one and its dependents.
> +An interactive tool would ask for user input to resolve many situations that cause port(1) to simply error out. 
> +All the suggested interactivity use cases are listed below-
> +1. If you try to install a port and one of its dependencies conflict with something already installed, it could ask if you want to 
> +   deactivate the installed one and its dependents and reactivate them after the build.

There are two different types of conflicts in MacPorts: activation-time conflicts, and build-time conflicts. The former is modeled by the "conflicts" keyword built into MacPorts base. The latter is modeled by the "conflicts_build" keyword in the conflicts_build 1.0 portgroup. What you're talking about refers only to build-time conflicts, not activation-time conflicts.

> +2. When trying to install a port but one of the files installed by this port is already present, ask the user whether the file should be
> +   overwritten.

We don't want to make it easy for the user to overwrite already-present files, because it's almost always wrong for the user to do this. We currently require the user to try again with the -f flag to indicate that they really want to force the operation. If MacPorts is enhanced to automatically ask the user if they want to do this, it should include a message that the correct answer is usually no.

> +3. When a user tries to install a port, display a list of ports that will be installed as dependencies and ask for confirmation (unless
> +   there aren't any dependencies to be installed), like apt-get does.

This could be a good idea, as long as there's a way to turn this feature off for those who want to script MacPorts non-interactively.

> +4. Asking for permission in a situation where uninstalling a package will break another package that's still installed and depends on   
> +   the to-be-uninstalled package.

This is another situation where we currently require the user to use the -f flag to indicate that they really do want to break the port's dependents.

> +5. When installing a port that requires a dependency to have a certain variant, but this variant is not set. Ask the user if it should  
> +   reinstall the dependency with that variant.

MacPorts base doesn't have a way to specify a dependency on a variant, but the active_variants 1.1 portgroup has been added for this. Ideally, ports would not depend on variants of other ports. Ideally, any quality of a port that another port would need to depend on would be expressed as a subport, not as a variant. Unfortunately, our ports are not in an ideal state. If MacPorts is enhanced to offer the user the choice to reinstall a dependency with another variant, it must make it clear that this could break any already-installed dependents that relied on the previously-selected variants. 

> +6. When activate is ambiguous, present a list of installed ports for the user to choose from.
> +7. Ask user before rebuilding in rev-upgrade.
> +8. When a user uninstalls a port using --follow-dependencies, the list of dependencies will be displayed and the user will be asked for  
> +   confirmation.