/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