/opt/local/macports/software

[Ryan Schmidt]

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

> On Tuesday January 20 2015 17:42:27 Ryan Schmidt wrote:
> 
> Why in fact deactivate and then activate anew? Isn't an untar of the appropriate tarball enough?

That's true, but the MacPorts commant to untar the tarball is "activate", and MacPorts will not allow you to "activate" a port that is already active, so you deactivate it first. If you prefer to figure out the command to untar the tarball and run that manually instead of using port commands, you can do that. It's never occurred to me before. I don't think the type of people who typically get into this situation are the ones who would want to do that.


>> Granted, in the case that the user has installed such a third-party installer, I actually recommend they completely uninstall MacPorts and all ports, then reinstall MacPorts and the desired ports, to be sure that no additional unwanted files are in /opt/local.
> 
> Something related came up in another discussion I had today, which raised the question how hard it would be to write a walker that 1) identifies stray and/or trespassing files

I wrote a script to do that in 2009. The problem is that a normal proper MacPorts installation actually contains many many files that are not registered to a port. That includes all files provided by MacPorts base, cache files, log files, config files...

> and 2) compares files with the copy in the software archive.

I haven't considered writing such a script. Sounds easy enough to do, but it would only be useful in situations where the user has corrupted their MacPorts-installed files, e.g. by running a badly-made third-party installer. I would rather focus effort on avoiding that situation ever happening in the first place. For example, whenever someone reports that this situation has occurred to them, we should attempt to discover which third-party installer they have used, then work with the developer of that third-party installer to fix it so that it no longer overwrites our files, and improving our documentation to explain to third-party developers how to create installers that avoid this problem.