Feature request: Ability to specify that installers may be deleted from /usr/local/Caskroom

[fgimian]

Description of feature/enhancement

Currently, a large amount of software installed via Cask appears to retain its installers and such in /usr/local/Caskroom

e.g.

Fotiss-MBP:~ fots$ ls -lh /usr/local/Caskroom/microsoft-office/15.29.16120900/
total 3276488
-rw-r--r--  1 fots  staff   1.6G 10 Dec 01:48 Microsoft_Office_2016_15.29.16120900_Installer.pkg

In most cases where an uninstaller is not present, keeping these packages around is not required and can waste a lot of space.

I suggest that an additional call is added which Cask writers can make that specifies that the contents of the original package can be purged after installation has completed. The default would be the current behaviour as to not break existing Casks.

Justification

Even today, storage on Macs is extremely expensive and in lower end MacBooks and MacBook Pros with 256 GB storage, this can really eat up a person's disk with no benefit.

Example use case

e.g. in my case with many of my own casks added too

Fotiss-MBP:~ fots$ du -sh /usr/local/Caskroom
 32G	/usr/local/Caskroom

[fgimian]

Could potentially be solved by #22647 although I do believe that Cask writers will need to specify if contents could be cleaned up, as some (albeit few) Casks depend on uninstallers.

[vitorgalvao]

I suggest that an additional call is added which Cask writers can make that specifies that the contents of the original package can be purged after installation has completed

A lot of overhead and complications to cask files with little gain.

Simply having casks that use pkg delete their pkg would already cover most of the cases and require no added complexity and maintenance to cask files.

[fgimian]

Thanks for your reply @vitorgalvao, anything that can save extra lines in Cask definitions is of course ideal.

I suppose the complication is that some pieces of software using a pkg file have additional files extracted that must also be deleted. And of course, there are cases where certain files are needed for uninstall:

e.g.

Fotiss-MacBook-Pro:~ fots$ brew cask cat virtualbox
cask 'virtualbox' do
  ...
  uninstall script:  {
                       executable: 'VirtualBox_Uninstall.tool',
                       args:       %w[--unattended],
                     },
            pkgutil: 'org.virtualbox.pkg.*'
  ...
end
Fotiss-MacBook-Pro:~ fots$ ls -l /usr/local/Caskroom/virtualbox/5.1.12-112440/
total 183208
-rwxr-xr-x  1 fots  staff   4357657 21 Dec 02:56 UserManual.pdf
-rw-r--r--  1 fots  staff  89426407 21 Dec 02:56 VirtualBox.pkg
-rwxr-xr-x@ 1 fots  staff     12307 21 Dec 02:56 VirtualBox_Uninstall.tool

Ideally, packages owners would specify what files to keep in the rare case like virtualbox and everything else would be deleted, but this would be break backwards compatibility 😢

[vitorgalvao]

some pieces of software using a pkg file have additional files extracted that must also be deleted

No additional files must be deleted. They might be to save space, but none is mandatory to delete. pkgs are often huge and useless after the installation is done, and are already referenced in casks, so I see no issue with removing those.

Adding a new feature and maintaining a list of files to delete after install will be worse than bikeshedding. In your example, there are three files: one is the installer (which we already established can be removed), other is an uninstaller (which is very much needed), and the third one is a pdf which may not be of use to you but might very well be of use to someone else. We’re not going to start making decisions on what is useful to users, that is not our goal.

[miccal]

Also remember that there Casks that use #{staged_path} (about 80 of them, actually) that may or may not require the install files to be kept.

I think it is best to leave the deletion to the user - for example, after running brew cask install mactex I then cd /usr/local/Caskroom/; rm -r mactex; because I know that the huge .pkg 😏 is not required to be kept.

[reitermarkus]

Keep in mind that once we have upgrade functionality, we might need the installer in this scenario:

If the upgrade fails, revert to the previously installed version using the previous installer.

[miccal]

I think that with the issues raised, and in light of #29301, at this stage it is best left to the user to clean up /usr/local/Caskroom if they wish.