Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Support pkg installers #14

phinze opened this Issue Sep 24, 2012 · 11 comments


None yet
6 participants

phinze commented Sep 24, 2012

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:


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 pushed a commit that referenced this issue May 12, 2013

a beta pkg installer
- the vagrant cask is our guinea pig
- works for me
- only basic testing at the moment
- i wanted to push something to get the gears turning on this

it turns out the concept is pretty simple. specify a list of pkgs to
install; borrow the patterns from linkables for that. then basically
just run "sudo installer"

refs #14

phinze commented May 12, 2013

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 commented May 12, 2013

Works great with vagrant!


vitorgalvao commented May 13, 2013

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 commented May 13, 2013


Crazor commented May 13, 2013

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 commented May 13, 2013

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'

@Crazor's version:

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

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 commented May 14, 2013

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 commented May 14, 2013

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 commented May 14, 2013

with an explicit uninstall a cask also better to read


phinze commented May 14, 2013

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.

moul added a commit to moul/homebrew-cask that referenced this issue May 21, 2013


phinze commented Jun 15, 2013

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

@phinze phinze closed this Jun 15, 2013

@miccal miccal removed the enhancement label Dec 23, 2016

colindunn pushed a commit to colindunn/homebrew-cask that referenced this issue Jan 12, 2017

victorpopkov pushed a commit to victorpopkov/homebrew-cask that referenced this issue May 2, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment