[MacPorts] #66524: Autoremove macports/software not to waste space with archived duplicates

[MacPorts]

#66524: Autoremove macports/software not to waste space with archived duplicates
--------------------------+--------------------
  Reporter:  esbugz       |      Owner:  (none)
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  base         |    Version:  2.8.0
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------

Comment (by esbugz):

 Replying to [comment:6 kencu]:
 > The official policy of homebrew is that they will not support users
 building their own software. This has been stated hundreds of times when
 people post up issues.

 Regardless of the "official policy", Homebrew does allow building from
 source, so this in itself is not a reason for the difference in behavior


 Replying to [comment:7 kencu]:
 > To really test what happens when you delete the "software" folder, you'd
 need to do some digging... like try to deactivate and reactivate a port

 Currently deactivating deletes the port, though the guide is a bit
 confusing as to what's supposed to happen
 > it deactivates it, i.e., it stashes the files belonging to the older
 version away in a tarball.

 This suggests that the files are not deleted, but move to an archive

 > Deactivating a port only removes the files from their activated
 locations (usually under ${prefix})—the deactivated port's image is not
 disturbed.

 This says they're removed

 So you could fix this by zipping the port on deactivation and putting it
 back to `/software` if it's empty, or you could skip autodelete to flagged
 ports (or automatically to ports with multiple versions), but the cleaner
 solution would be similar to what Homebrew does, so
 activating/deactivating would mean symlinking to the port's install folder
 rather than moving the files while leaving a backed up duplicate version
 behind


 > try it in a non-default prefix where the prebuilt packages can't be used
 > and try to rebuild something where the default stdlib has been changed
 to "libstdc++" from "libc++" for example.

 That defeats the core benefit of MacPorts, but then it's also fine just
 disabling autoremove functionality in such cases and let the user opt in


 > These are all the kinds of assumptions that homebrew never has to make,
 because they don't really support any of this.

 Sure, they strongly advise against it and will close your issues, but them
 some people still installed to their home folder, for example, with the
 same huge downside - you'd have to rebuild everything from source instead
 of using the prebuilt packages from their cache.

 But even then, none of this assumptions affect the most convenient use
 case of installing with the default prefix and relying on prebuilt
 packages, so none of them block removing the waste

-- 
Ticket URL: <https://trac.macports.org/ticket/66524#comment:9>
MacPorts <https://www.macports.org/>
Ports system for macOS