On May 17, 2014, at 06:29, MacPorts <[email protected]> wrote: > Page "SummerOfCode" was changed by [email protected] > 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. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
