Identifying possible situations for interactivity

[Jan Stary]

On Sep 01 12:12:11, egall at gwmail.gwu.edu wrote:
> So I was going thru my drafts folder and found this unsent message in
> it from a few years ago; much of it may no longer be relevant now that
> MacPorts has already added interactivity, but I figured I might as
> well send this anyways for the archives so what I wrote doesn't die
> stuck in my drafts.

The port system should be as NON-interactive as possible.
A user starts a bulk build of, say, all audio ports and walks away.
It would be quite unfortunate if he had to be there the whole time.

The exeptions should only be exceptional: when a port is removed,
everything that depends on it should also be removed, but that
probably requires the user's Yes.

>  - after running `selfupdate`, MacPorts could ask the user if they
> next want to upgrade    all their outdated ports.

No. This insistence on the latest bugs is a disease.
I want the version I have, which I know to work, unless I have
a reason to update (such as a security problem or a feature I wanted).

>  - modifications to configuration files:
> {{{
> Configuration file `/sw64/etc/shells'
>  ==> File on system created by you or by a script.
>  ==> File also in package provided by package maintainer.
>    What would you like to do about it ?  Your options are:
>     Y or I  : install the package maintainer's version
>     N or O  : keep your currently-installed version
>       D     : show the differences between the versions
>       Z     : background this process to examine the situation
>  The default action is to keep your current version.
> *** shells (Y/I/N/O/D/Z) [default=N]
> }}}

An install should never touch configs in /etc (let alone in $HOME),
except if creating a brand new one. Notify the user that a port contains
a config different from one that aready exists, or has installed a new one,
and leave it to the user to do the editing.