/opt/local/macports/software

[Ryan Schmidt]

On Jan 20, 2015, at 2:12 AM, Akim Demaille wrote:
> 
> Le 19 janv. 2015 à 11:07, Ryan Schmidt 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.
> 
> I have a question: what exactly is in the archive?

You can decompress it yourself to take a look: it contains all the files installed by the port, and also a copy of the Portfile itself and some other metadata.

> Why is that that
> deactivate does not archive what was installed on the disk?  I mean,
> if the archives is exactly what is deployed, then it's pure duplication,
> including in an activate/deactivate scenario: one copy should be enough,
> be it deployed, or compressed, no?  Maybe that would be less invasive,
> I don't know.

Because nobody (at least not me) thought to program it that way.

There is also a problem which occurs more often than it should, which is this: a user installs MacPorts in its default prefix, and installs some ports, and then installs a third-party software installer, which was itself built with MacPorts in its default prefix. Developers should not create installers of MacPorts-provided software with MacPorts in its default prefix (they should custom-configure MacPorts to a prefix unique to their software), but they do. Users should not install such misconfigured installers, but they do. And the consequence is that the files of some the user's installed ports are now overwritten with older versions, or versions built for the wrong architecture. Currently, a user can work around that by deactivating the port (i.e. deleting all the files the port installed), then reactivating the port (i.e. decompressing the archive which contains the correct versions of the files). If the archive isn't there, and is recreated by deactivating, then deactivating and reactivating does nothing useful, and additionally takes a lot more time than it does now.

Granted, in the case that the user has installed such a third-party installer, I actually recommend they completely uninstall MacPorts and all ports, then reinstall MacPorts and the desired ports, to be sure that no additional unwanted files are in /opt/local.