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.


_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Reply via email to