/opt/local/macports/software

[Akim Demaille]

> Le 19 janv. 2015 à 11:07, Ryan Schmidt <ryandesign at macports.org> a écrit :
> 
> On Jan 19, 2015, at 3:59 AM, Akim Demaille wrote:
>> You're talking implementation details, I'm talking feature.  And the
>> implementation is straightforward: rm -f /opt/local/macports/software/<PORT>
>> when <PORT> was activated.
> 
> It's quite a lot more than just that. You're asking for a way for the user to opt in to auto-removal of archives and opt out of the ability to use the deactivate feature. MacPorts currently relies on the deactivate feature during uninstallation, so there would be changes required there as well.

You are right.

>> Yes, I'm sure it's nice.  I'm not saying the feature is useless, I'm
>> saying I don't want to use it.
> 
> There are situations where MacPorts will advise you that an installation you requested cannot proceed until you deactivate (or uninstall) a particular port (the conflicts_build portgroup). Making deactivation impossible would be inconvenient in those cases.

Well, AFAICT, it basically amounts to s/deactivate/uninstall/ in the
error messages.

> 
> 
>>> apt-get is not typically used on OS X, which is the platform where concerns regarding Spotlight and Time Machine occur. It would be more interesting to compare against the other OS X package managers, Homebrew or Fink.
>> 
>> I don't see how the OS is relevant in anyway here.
> 
> It's relevant if we're discussing why MacPorts was changed to work the way it does today. It's not relevant provided you're willing to opt out of being able to deactivate a port.

I'm not suggesting to change anything in the way its builds, installs,
activates anything.  This is robust, works well, there's no reason to
take chances with that part of the code.

I'm talking about removing the copy kept in that directory at the
end of the process.