If you are just looking to save some space at the expense of time, you could set:<br>
<br>
portarchivetype txz<br>
<br>
in macports.conf; on some of the big clang/llvm archives this is ~2x improvement...<br>
<br>
On Wed, May 18, 2016 at 12:16 PM, Ryan Schmidt <<a href="javascript:;" onclick="_e(event, 'cvml', 'ryandesign@macports.org')">ryandesign@macports.org</a>> wrote:<br>
><br>
>> On May 17, 2016, at 5:38 PM, Nicolas Martin <<a href="javascript:;" onclick="_e(event, 'cvml', 'nicolas.martin.3d@gmail.com')">nicolas.martin.3d@gmail.com</a>> wrote:<br>
>><br>
>>><br>
>>> On May 17, 2016, at 5:15 PM, Clemens Lang <<a href="javascript:;" onclick="_e(event, 'cvml', 'cal@macports.org')">cal@macports.org</a>> wrote:<br>
>>><br>
>>> On Tue, May 17, 2016 at 10:58:56AM -0400, Nicolas Martin wrote:<br>
>>>> I have looked for real answers regarding this question through the<br>
>>>> mailing list, but did not really understand the purpose of these<br>
>>>> files.<br>
>>><br>
>>> MacPorts always keeps a tarball of the files installed by a certain<br>
>>> port in this directory. This allows you to switch between installed<br>
>>> versions or between ports that would otherwise conflict without<br>
>>> re-installing them completely. port activate/port deactivate implement<br>
>>> this.<br>
>><br>
>> Is there a way to have MacPorts behave so as to completely reinstall a port if one needs to ?<br>
><br>
> Regarding switching between installed versions of a port: MacPorts does not have the capability to build an arbitrary version of a port, only the current version of a port. So if you might want to switch back to an older version, you should keep it installed. Otherwise you have to perform manual steps to rebuild the old version as described here:<br>
><br>
> <a href="https://trac.macports.org/wiki/howto/InstallingOlderPort" target="_blank">https://trac.macports.org/wiki/howto/InstallingOlderPort</a><br>
><br>
> Regarding switching between conflicting ports: If you don't want to keep both ports installed, for example for disk space reasons, you can of course uninstall one port and install the other. Then, to switch back, you can uninstall the second port and reinstall the first.<br>
><br>
><br>
>> I would prefer to wait through the process of building and activating the port again if I need to, than to lose quite a lot of space with duplicated binaries I almost never have to activate again.<br>
>><br>
>>> The rationale here is that after an update you can test the updated<br>
>>> version of a software for a while, and if you notice it causes problems<br>
>>> you can file a ticket and easily go back to the old version with a<br>
>>> simple<br>
>>> sudo port activate @oldversion<br>
>><br>
>> I understand this, but if you never have to revert to an older version of a package, this is quite a waste of space.<br>
><br>
> It's also not entirely uncommon for a user to discover that some of a port's files have vanished or been replaced with the wrong contents, for example by running a third-party installer that installed older files into the MacPorts prefix. Some of these types of problems can be resolved by deactivating and then reactivating the affected ports, which you couldn't do if you didn't have an archive there.<br>
><br>
> The decision to store these archives on the disk was made with the assumption that disk space is cheap, and becoming cheaper. And while disk space is indeed getting cheaper, we didn't anticipate the rise of more-expensive-yet-smaller SSDs.<br>
><br>
>><br>
>>><br>
>>> MacPorts used to keep these files in a directory and just hard-link them<br>
>>> into $prefix, but that (a) means modifications to files in $prefix<br>
>>> affect the supposed-to-be prinstine copy, and (b) isn't easy to download<br>
>>> as pre-built binary. For this reason, we switched to tarballs a while<br>
>>> back and now provide pre-built binaries for some of these tar balls.<br>
><br>
> Another reason was that hard links didn't play nicely with Time Machine.<br>
><br>
><br>
>>>> I have almost 5Gb of archives (tbz2) in<br>
>>>> /opt/local/var/macports/software.<br>
>>><br>
>>> You seem to have quite a few ports installed. My software directory is<br>
>>> 3.4G with 652 installed ports.<br>
>><br>
>> Well clang and llvm occupies a whooping 1.2G by themselves alone.<br>
><br>
> True, clang and llvm are large. But according to<br>
><br>
> <a href="https://packages.macports.org/llvm-3.7/?C=M;O=D" target="_blank">https://packages.macports.org/llvm-3.7/?C=M;O=D</a><br>
><br>
> llvm-3.7 is 377MB and according to<br>
><br>
> <a href="https://packages.macports.org/clang-3.7/?C=M;O=D" target="_blank">https://packages.macports.org/clang-3.7/?C=M;O=D</a><br>
><br>
> clang-3.7 is 357MB. If you're seeing twice that size on your system, maybe you've installed it with the universal variant.<br>
><br>
><br>
>>>> I have already run the port uninstall inactive command, so from my<br>
>>>> understanding, what remains in this path is from currently active and<br>
>>>> used ports.<br>
>>><br>
>>> Correct.<br>
>>><br>
>>>> What I don’t understand, and does not seem to be clear from any posts<br>
>>>> I have read regarding the matter, is why should these archives be<br>
>>>> kept?<br>
>>><br>
>>> If you delete those archives you can no longer deactivate and<br>
>>> re-activate a port. In addition to the use case above, this is also<br>
>>> helpful when one of the files installed by the port was corrupted for<br>
>>> some reason -- just de- and re-activate it.<br>
>><br>
>> I suppose that if I were to manually delete those archives, MacPorts would not be so kind as to detect this and just start the build process over again, if he needs to ?<br>
><br>
> Deactivating a port for which you've deleted the archive would probably succeed, since the information about what files to remove comes from the registry and not from the archive, but attempting to reactivate it would probably give you an error message. Manually removing archives of installed ports from the software directory is not something we support at this time. MacPorts does not expect you to do that, and its behavior if you do is undefined.<br>
><br>
><br>
>> Would it be safe then to have some of /opt/local/var/macports symlink-ed on an external hard drive ?<br>
><br>
> For the top level directories, I would say yes. I have had /opt/local/var/macports/distfiles symlinked elsewhere for years with no problems.<br>
><br>
><br>
>> I would only plug the drive if I need to activate/deactivate those old (and large) ports, but small ports would be stored on my main drive.<br>
>> Would MacPorts still function with such a setup ?<br>
><br>
><br>
> Doing that would be unsupported, but it might work. At least until you uninstall the last version of a port: at that point, MacPorts would remove the directory (or in your case symlink) for that software. When you next install that software, a new directory would be created.<br>
><br>
> Also, I don't know what kind of problem you might encounter if you forgot to plug in the drive while dealing with one of those ports whose software directories you had symlinked.<br>
><br>
><br>
> _______________________________________________<br>
> macports-users mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'macports-users@lists.macosforge.org')">macports-users@lists.macosforge.org</a><br>
> <a href="https://lists.macosforge.org/mailman/listinfo/macports-users" target="_blank">https://lists.macosforge.org/mailman/listinfo/macports-users</a><br>
<br>