Support pkg installers

[phinze]

Command line pkg install

It's definitely possible to use the installer tool from the command line on pkgs. Should be able to build on some of my previous work from here:

https://github.com/phinze/puppet-workstation/blob/master/modules/puppet-macosx/lib/puppet/provider/package/macapp.rb#L74-87

Target the Caskroom

The real tricky part is to see if we can get the installer to target the Caskroom path, so that we keep the sexy Homebrew isolation of packages.

I've done some initial exploratory work on this - it seems like pkgs can be locked down such that they can only target a root volume.

There are a few strategies to try:

• Trick installer into thinking a Caskroom path is a "volume" suitable for targeting
• Modify the downloaded pkg to change the flag forcing the install to target a root volume

Now of course even if we pull this off, it may break some packages that rely on absolute path references to work. We can deal with that problem on a cask-by-cask basis.

Escalate privileges for some packages?

So if we can't do the Caskroom isolation for, say, virtual-box - I'd still like brew-cask to be able to manage that installation. So I'd like to explore whether we can have brew-cask

• get root privileges
• let the pkg have its way with the system
• somehow manage the installed package even though it's not in the Caskroom

Fun times ahead!

[phinze]

Alright finally the start of a pkg installer feature! Going to see if I can get a few people trying it on Vagrant and then slowly add it to a few more casks.

Slowly but surely progress! 👻

[Crazor]

Works great with vagrant!

[vitorgalvao]

Installation works well here, too. However, it breaks brew cask uninstall for that specific cask.

When we link apps, more than one file may need to be used, while with installers it’s only one (the installer itself) and these come usually with an uninstaller (uninstall.tool for vagrant, VirtualBox_Uninstall.tool for virtualbox, Uninstall.app for xtra-finder) so maybe we could take advantage of this, and have a syntax like install 'Installer.pkg', 'Uninstaller.tool'.

We should never have more than one installer and one uninstaller, so if there are two options, it'd assume the first is the installer, and the second the uninstaller.

[passcod]

👍 @vitorgalvao

[Crazor]

couldn't hurt to make it explicit, with seperate install 'Installer.pkg' and uninstall 'Uninstaller.tool' lines. I think i've seen DMGs with more than one .pkg with some Brother drivers.

Maybe we could even copy the uninstaller tool to the caskroom to have it available without redownloading the whole package to remove it.

[phinze]

I like the idea of trying to track uninstallers too. 👍

Let's try some syntax highlighting to get a feel for how it should look.

@vitorgalvao's original suggestion:

class Vagrant < Cask
  url '...'
  # ...
  install 'Vagrant.pkg', 'Uninstall.tool'
end

@Crazor's version:

class Vagrant < Cask
  url '...'
  # ...
  install 'Vagrant.pkg'
  uninstall 'Uninstall.tool'
end

I think I lean towards the explicit uninstall keyword. I could see down the road supporting more complex uninstall directives that just contained an explict script. Or maybe eventually we'll support for parsing /var/db/receipts files to uninstall. Having a keyword gives us more room to grow there.

But I don't feel super strongly - I'm down to talk about other arguments too.

Maybe we could even copy the uninstaller tool to the caskroom to have it available without redownloading the whole package to remove it.

This already happens automatically. The Caskroom keeps everything that was in the original DMG. 😄

[Crazor]

Oh I didn't notice that. I think it's not too useful to keep anything but the uninstaller around. I'm always hunting wasted disk space ever since I got that Air ;)

[vitorgalvao]

Even though I sympathize with not wanting to fill the disk with stuff we probably won’t need, I don’t think it’s a viable option in this case. I say this because there are .dmg files that do come with more than just the (un)installers (optional plugins, CLI components), so getting rid of these automatically can be bad for certain casks.

You might want to run brew cleanup --force -s && rm -rf $(brew --cache) regularly to free some space, though.

Regarding syntax, I agree with specifying uninstall — it’s more “future-proof”.

[muescha]

with an explicit uninstall a cask also better to read

[phinze]

Cool; we'll go with uninstall. I've got a little prototype working locally, and I'll try to clean it up and push it this week.

[phinze]

Since we landed this, I'm going to call this one done and split off a separate issue for finishing uninstall commands, which I'm working on