| 254 | | 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. |
| | 254 | An interactive tool would ask for user input to resolve many situations that cause port(1) to simply error out. |
| | 255 | All the suggested interactivity use cases are listed below- |
| | 256 | 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 |
| | 257 | deactivate the installed one and its dependents and reactivate them after the build. |
| | 258 | 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 |
| | 259 | overwritten. |
| | 260 | 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 |
| | 261 | there aren't any dependencies to be installed), like apt-get does. |
| | 262 | 4. Asking for permission in a situation where uninstalling a package will break another package that's still installed and depends on |
| | 263 | the to-be-uninstalled package. |
| | 264 | 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 |
| | 265 | reinstall the dependency with that variant. |
| | 266 | 6. When activate is ambiguous, present a list of installed ports for the user to choose from. |
| | 267 | 7. Ask user before rebuilding in rev-upgrade. |
| | 268 | 8. When a user uninstalls a port using --follow-dependencies, the list of dependencies will be displayed and the user will be asked for |
| | 269 | confirmation. |
