| 29 | | An interactive tool would ask for user input to resolve many situations that cause port(1) to simply error out. |
| 30 | | |
| 31 | | All the suggested interactivity use cases are listed below- |
| 32 | | |
| 33 | | 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 |
| 34 | | deactivate the installed one and its dependents and reactivate them after the build. |
| 35 | | 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 |
| 36 | | overwritten. |
| 37 | | 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 |
| 38 | | there aren't any dependencies to be installed), like apt-get does. |
| 39 | | 4. Asking for permission in a situation where uninstalling a package will break another package that's still installed and depends on |
| 40 | | the to-be-uninstalled package. |
| 41 | | 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 |
| 42 | | reinstall the dependency with that variant. |
| 43 | | 6. When activate is ambiguous, present a list of installed ports for the user to choose from. |
| 44 | | 7. Ask user before rebuilding in rev-upgrade. |
| 45 | | 8. When a user uninstalls a port using --follow-dependencies, the list of dependencies will be displayed and the user will be asked for |
| 46 | | confirmation. |
| | 29 | 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 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. |
