/opt/local/macports/software

Ryan Schmidt ryandesign at macports.org
Wed Jan 21 22:32:44 PST 2015


On Jan 21, 2015, at 4:24 AM, René J.V. Bertin wrote:

> On Tuesday January 20 2015 19:25:11 Ryan Schmidt wrote:
> 
>>> Why in fact deactivate and then activate anew? Isn't an untar of the appropriate tarball enough?
> 
>> 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.
> 
> :) I guess one could argue that `port activate -f` (or is that -f activate...) could/should do that?

I don't know whether "port -f activate" would do anything, or do anything useful, on a port that is already active.


>> 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...
> 
> Those are all in the portdbpath, no? 

I'm speaking of files like:

>> all files provided by MacPorts base,

e.g. /opt/local/bin/port, /opt/local/bin/portindex, /opt/local/etc/macports/macports.conf.default, etc.

Not to mention everything in /opt/local/var/macports/

>> cache files,

e.g. everything in /opt/local/var/cache/fontconfig/, etc.

>> log files,

e.g. /opt/local/var/log/mongodb/mongodb.log, /opt/local/var/log/nginx/access.log, etc.

>> config files...

e.g. /opt/local/apache2/conf/httpd.conf, /opt/local/etc/macports/macports.conf, /opt/local/etc/php55/php.ini, etc.




More information about the macports-users mailing list