automatic port clean

[Ryan Schmidt]

On Jan 20, 2015, at 2:20 PM, René J.V. Bertin wrote:

> On Tuesday January 20 2015 14:29:10 Lawrence Velázquez wrote:
> 
>> We should not implement needlessly fine-grained persistent preferences for every possible behavior. I expect that very few users (besides you, apparently) would use this preference.
> 
> Fair enough, if I'm the only one with memory glitches :)
> 
> Could this kind of functionality be implemented through something like a plugin feature if that existed?

There are no plugins. You can create a shell function in your shell startup script to do this and many other interesting things. It is a bad idea to do this, but for the sake of an example, using bash:

port() {
	command sudo port -o "$@"
}

Now, anytime you begin a command with "port", your shell will actually begin the command with "sudo port -o". So if you type "port install zlib" the shell will actually run "sudo port -o install zlib".

One problem is that there is no flag that means the opposite of "-o", so once you've enabled it globally in this way, there is no way to selectively indicate that you want to disable the option again.

I don't want to add a config file option to allow the user to do this. Users will enable the option without understanding the implications, or will forget that they have enabled the option, and will run into strange problems that they will report to us, which we will then have to expend energy in trying to solve. It will increase our support burden and I do not want to do that. Quite the contrary: I look for ways to decrease our support burden.

Imagine a user has enabled your hypothetical conf option for default-enabling "-o". The user then tries to install a port, and let's say it fails during the build phase. They file a bug report, and we fix the port. All a normal user should have to do is "sudo port selfupdate" and then try installing that port again. MacPorts will notice the change to the portfile, clean the work directory, start from scratch, and hopefully it will work this time. But because this user has enabled the option not to clean on portfile changes, MacPorts will try to pick up where it left off. This might fail again. The user would have to manually clean the work directory, and the user might not know that, and might ask for help. Even worse, the build might succeed, but might not include all of the fixes (some of the fixes may have been in phases earlier than the build phase).

I could even go so far as to imagine this scenario: a user extracts a port which is at version 1.0. Maybe they patch and configure and build and destroot too, but one way or another the process is interrupted before the port is installed. Now the user runs "sudo port selfupdate", which happens to include an update of this port to version 1.1. Now the user installs the port. The version of the software that has actually been installed is 1.0, because the incomplete installation of version 1.0 was in the user's work directory and MacPorts didn't auto-clean it because of your config option, but the registry indicates that version 1.1 has been installed, because that's what they portfile now says, and no further use of the port command will ever indicate to the user that this has happened nor give them a way to upgrade to the correct version. The user would have to somehow realize this has happened (i.e. by using the program's "--version" flag, or looking in the program's about box), and then know that they should use "sudo port -n upgrade --force" to rebuild it properly.

I do not want to empower the user to make all these mistakes.