/opt/local/macports/software

[Ryan Schmidt]

On Jan 19, 2015, at 5:34 AM, René J.V. Bertin wrote:

> On Monday January 19 2015 04:07:40 Ryan Schmidt wrote:
> 
>> 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.
> 
> Does deactivation become impossible when the software/foo/tarball has been removed?

No, but re-activation would be impossible, therefore deactivation should be prevented.

> Are the contents of that tarball used to determine which files to remove, for instance?

No, that's stored in the registry.


>>>> 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.
> 
> What issues with SpotLight and/or Time Machine? 

Spotlight would find items in the /opt/local/var/macports/software directory. So when you were trying to launch an application in /Applications/MacPorts, it might find the copy in /opt/local/var/macports/software instead, which might not work.

Time Machine would back up two copies of each item -- the real one in /opt/local and the one in /opt/local/var/macports/software -- because Time Machine doesn't understand hard links (which is not Time Machine's fault; hard links are designed to look just like independent files).


> If there are, it would be possible to provide a port command or script that adds certain directories to their respective exclusion lists. AFAIK that can be done from the commandline and thus also from scripts.

That would be a possible solution for the Spotlight issues but not for the Time Machine issues.


>> 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.
> 
> IMHO, suggesting an option for MacPorts not to support deactivation/activation is like suggesting that feature as an option to apt/dpkg.

I agree code could be written to add this option to MacPorts. But someone would have to write and test that code. The assumption that archives exist is pervasive in MacPorts; I suspect code changes would be needed throughout base. And I am not convinced this extensive effort is worthwhile, given the drawbacks making use of this option, that have been discussed in this thread, would entail. I agree that reducing disk usage is good, but I don't think trying to make /opt/local/var/macports/software optional is the best way to achieve that. The "port reclaim" command which will be in MacPorts 2.4 is an effort at letting you reclaim unnecessarily used disk space. There are probably additional ways in which it could help you in that regard, and we should continue to improve it in the future.


> What could be an option:
> - remove inactivated ports by default after a port upgrade

You can use the "-u" flag when you run "sudo port upgrade" (i.e. "sudo port -u upgrade"), but it cannot currently be made the default. You could create a shell function to do that.

> - use xz instead of bzip2 to compact things a bit more

Whatever compression format is used needs to be supported without the use of any port. OS X does not include support for dealing with xz files, which is one reason why bz2 files were chosen instead. Changing this would involve bundling a copy of the xz utilities with MacPorts; changing the default archive format from bz2 to xz in archive_sites.conf and macports.conf; re-building all ports on all buildbot builders with this new version of MacPorts; and upgrading all users to this new version of MacPorts. I also do not know what would happen if a user who already has ports installed with bz2 archives suddenly changes the archive format to xz (or, more generally, makes any change to the archive format). Would MacPorts still know how to find the existing archive and remove it when a port is uninstalled or upgraded?

> - the place where such large things are stored, which are required only when doing port maintenance or development.

The software directory is used during normal port installation. You could possibly symlink it to another drive if space is tight on your main drive; I haven't tested this thoroughly to know if it works well enough.


> That latter option would also allow using a case-sensitive fs for the build/work directories, which could be beneficial (e.g. make post-extract adaptations to a case-insensitive target fs possible).

Let's not bring case sensitivity into this discussion, which is about reclaiming disk space. MacPorts can be installed on case-sensitive systems and on case-insensitive systems, but it is a bad idea to have a single MacPorts installation try to interact with both types of filesystems. For example, do not have /opt/local be on a case-insensitive filesystem but have /opt/local/var/macports/build be on a case-sensitive filesystem, or vice-versa. If any individual port cannot be installed, whether due to case sensitivity of filesystem or other reason, that bug should be reported and fixed.


> What parts of ${prefix}/var/macports are used during normal operation, so as long as you don't use the port command?

None. That directory is for the port command to use, and nobody else.