Getting rid of port binaries in /software

Wed May 18 15:25:50 PDT 2016

If you are just looking to save some space at the expense of time, you
could set:

portarchivetype      txz

in macports.conf; on some of the big clang/llvm archives this is ~2x
improvement...

On Wed, May 18, 2016 at 12:16 PM, Ryan Schmidt <ryandesign at macports.org
<javascript:;>> wrote:
>
>> On May 17, 2016, at 5:38 PM, Nicolas Martin <nicolas.martin.3d at gmail.com
<javascript:;>> wrote:
>>
>>>
>>> On May 17, 2016, at 5:15 PM, Clemens Lang <cal at macports.org
<javascript:;>> wrote:
>>>
>>> On Tue, May 17, 2016 at 10:58:56AM -0400, Nicolas Martin wrote:
>>>> I have looked for real answers regarding this question through the
>>>> mailing list, but did not really understand the purpose of these
>>>> files.
>>>
>>> MacPorts always keeps a tarball of the files installed by a certain
>>> port in this directory. This allows you to switch between installed
>>> versions or between ports that would otherwise conflict without
>>> re-installing them completely. port activate/port deactivate implement
>>> this.
>>
>> Is there a way to have MacPorts behave so as to completely reinstall a
port if one needs to ?
>
> 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:
>
> https://trac.macports.org/wiki/howto/InstallingOlderPort
>
> 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.
>
>
>> 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.
>>
>>> The rationale here is that after an update you can test the updated
>>> version of a software for a while, and if you notice it causes problems
>>> you can file a ticket and easily go back to the old version with a
>>> simple
>>> sudo port activate @oldversion
>>
>> I understand this, but if you never have to revert to an older version
of a package, this is quite a waste of space.
>
> 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.
>
> 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.
>
>>
>>>
>>> MacPorts used to keep these files in a directory and just hard-link them
>>> into $prefix, but that (a) means modifications to files in $prefix
>>> affect the supposed-to-be prinstine copy, and (b) isn't easy to download
>>> as pre-built binary. For this reason, we switched to tarballs a while
>>> back and now provide pre-built binaries for some of these tar balls.
>
> Another reason was that hard links didn't play nicely with Time Machine.
>
>
>>>> I have almost 5Gb of archives (tbz2) in
>>>> /opt/local/var/macports/software.
>>>
>>> You seem to have quite a few ports installed. My software directory is
>>> 3.4G with 652 installed ports.
>>
>> Well clang and llvm occupies a whooping 1.2G by themselves alone.
>
> True, clang and llvm are large. But according to
>
> https://packages.macports.org/llvm-3.7/?C=M;O=D
>
> llvm-3.7 is 377MB and according to
>
> https://packages.macports.org/clang-3.7/?C=M;O=D
>
> clang-3.7 is 357MB. If you're seeing twice that size on your system,
maybe you've installed it with the universal variant.
>
>
>>>> I have already run the port uninstall inactive command, so from my
>>>> understanding, what remains in this path is from currently active and
>>>> used ports.
>>>
>>> Correct.
>>>
>>>> What I don’t understand, and does not seem to be clear from any posts
>>>> I have read regarding the matter, is why should these archives be
>>>> kept?
>>>
>>> If you delete those archives you can no longer deactivate and
>>> re-activate a port. In addition to the use case above, this is also
>>> helpful when one of the files installed by the port was corrupted for
>>> some reason -- just de- and re-activate it.
>>
>> 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 ?
>
> 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.
>
>
>> Would it be safe then to have some of /opt/local/var/macports symlink-ed
on an external hard drive ?
>
> For the top level directories, I would say yes. I have had
/opt/local/var/macports/distfiles symlinked elsewhere for years with no
problems.
>
>
>> 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.
>> Would MacPorts still function with such a setup ?
>
>
> 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.
>
> 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.
>
>
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org <javascript:;>
> https://lists.macosforge.org/mailman/listinfo/macports-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20160518/7d620b81/attachment.html>