/opt/local/macports/software

Ryan Schmidt ryandesign at macports.org
Mon Jan 19 02:07:40 PST 2015


On Jan 19, 2015, at 3:59 AM, Akim Demaille wrote:
> 
> Le 19 janv. 2015 à 10:54, Ryan Schmidt a écrit :
>>> So maybe we could reconsider the existence of this feature, or at least,
>>> the fact that its mandatory.
>> 
>> If I remember correctly, the code for the old way with hard links was removed from MacPorts. There is no way to go back to that method, without rewriting the code.
> 
> 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.


>>> Well, apt-get and the rest have no such equivalent.  They just deploy
>>> the software, period.  They don't keep a copy at hand, just in case.
>>> And yes, there's no acivate/deactivate (that I know of).
>> 
>> If your installed files have become damaged, for example because a third-party installer overwrote them, it's very nice to be able to fix it by simply deactivating and re-activating the port.
> 
> 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.


>> 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.




More information about the macports-users mailing list