Hacker News Reader

Comment by jabirali | Hacker News Reader

> MacPorts has most of the same common packages and doesn't mess up filesystem permissions like Homebrew does.

This is more a convenience than security question. I understand that Homebrew can install not only open source command-line tools, but also third-party binaries (via `cask`) and Mac App Store apps (via `mas`), and that all three types of software can be installed, updated, or removed via the same `brew` command or synced `Brewfile`.

Does MacPorts offer something similar? In that case, how is its coverage compared to the systems above?

(Context: I’m a long-time Linux user in the process of migrating to macOS.)

View on HN

As I understand it, MacPorts is a fair bit more limited in that regard. For my purposes, I haven't found a need for the ability to install third-party binaries and Mac App Store apps through my package manager, since every third-party binary I have installed includes its own updater and the Mac App Store updates apps as well. I can see how setting up everything in one place could be useful, but I haven't run into a situation where it has been useful in my macOS usage quite yet.

Homebrew and MacPorts are philosophically pretty different from each other and neither can be directly compared to Linux package managers. I think you'll find the solution of MacPorts for OSS command-line tools + Mac App Store for Xcode and other random stuff + third-party installers for things like Sublime Text and Microsoft Office works pretty well in practice, although it's not quite as clean as using one package manager for everything.

Thank you for sharing your experience on this :).

> I can see how setting up everything in one place could be useful, but I haven't run into a situation where it has been useful in my macOS usage quite yet.

What appeals to me personally is having a list of apps (the “Brewfile”), that I can sync between my work and personal computer via my dotfiles, and let the system mirror what apps are installed on both devices (“brew bundle” installs or uninstalls apps based on that app list). And that if I need to replace my machine, I can just sync my dotfiles to new machine and let Homebrew autorestore apps, including third-party apps and things from App Store.

I’ve tried some “declarative package managers“ before and enjoyed that, so when articles like this [1] said Homebrew can apparently do the same across open-source software, Mac App Store apps, and third-party apps, via a single synced Brewfile, that seemed interesting. The same Brewfile also appears to be usable on Linux for open-source apps (via Linuxbrew).

But I don’t yet have any experience with it, so I have no idea how well it works or whether it’s worth it. If we disregard third-party apps, do you know if MacPorts has an equivalent to Brewfile?

[1]: https://openfolder.sh/macos-migrations-with-brewfile

Somewhat, it does have a way of recreating your current setup (generally intended to be used across OS upgrades, but doesn't have to be limited to that usecase): https://trac.macports.org/wiki/Migration

Cask doesn't just handle packaged GUI apps, but also binary distributions of command-line apps that are hard to compile from source; or are proprietary/closed-source; or are actually sandboxed point-release distributions of {software written in a scripting language + its vendored deps + its runtime}. None of these will have any sort of updater built into them, but they'll all be updated through `brew cask upgrade`. (Any random Golang binary you might download off of Github? Before I even Google it, I type `brew search $whatever` into my terminal. Way easier to keep updated than even the `go get`-installed version, and also doesn't require that you have go installed.)

As well, even for GUI software that has Sparkle-like update support built in, if you don't use it very often, it won't get updated until the next time you launch it, and even then will only get updated if you're online at the time you launch it. This leaves you vulnerable in the specific case that the software is offline but opening an untrusted document (e.g. one you originally downloaded from the network.) The vulnerability in the app will likely be exploited immediately upon launch of the app, before the app gets to update itself. Doing a periodic `brew cask upgrade` also takes care of these (at the annoying expense of constantly upgrading apps that put out a new release every few days. Looking at you, Etcher.)

Also, besides upgrading, brew is useful just for grabbing all this third-party software without having to run hither and thither to find it. Sometimes the only web route to downloading a piece of software involves one of those skeezy download-hosting sites that redirects you through several ad walls, or requires that you make an account to download. With brew, you skip all that — just e.g. `brew cask install megasync` or `brew cask install plex-media-server`.

Also, brew suppresses any interactive GUI elements of the install/update process, if it possibly can. `brew cask install java`, besides skipping navigating through ten pages of links to links to TOS agreements to links on Oracle's website, also does not summon forth the Java installer GUI, but rather does everything in the command-line. (As far as I can tell, it doesn't install the Java updater, either; brew takes over responsibility for upgrading Java, so there's no need for an independent update checker.)

And there's also `brew cask zap`, which is an uninstaller that actually cleans up after the program, removing not only the application itself, but also all the stuff the app either installed, or later created at runtime, under /Library. This takes advantage of Apple .pkg BOM manifests if it can; but also has a manually-specified section in brew formulae, to allow it to zap away the cruft of apps that don't bother to keep track of themselves (e.g. Zoom, zerotier, usboverdrive, switchresx, etc.)

There's also `brew services` — brew packages (and I think brew casks, too) can install launchd unit-file templates; and you can then enable/disable these (i.e. [un]link them in ~/Library/LaunchDaemons), and manage the lifecycle of (start/stop/status) these (i.e. call into launchctl), through `brew services`.

(My own `brew services` currently contains: docker-machine, ifs, postgresql, reds, ssh-askpass, unbound. I use it quite a lot! Much less arcane than launchctl itself.)

-----

Oh, and disregarding all that, and addressing the assumption underlying your arguments (that homebrew "messes with the filesystem"): you can keep a brew installation that doesn't mess with the filesystem at all (see https://docs.brew.sh/Installation#untar-anywhere).

It's just that doing so will confuse exactly the type of pre-compiled CLI (or POSIX-y GUI) tools that `brew cask` is meant to help you install. These would be the ones where important paths (e.g. $PREFIX/etc, $PREFIX/share) are burned into the compiled binary, and so by necessity one fixed prefix has to be selected to burn in at compile time. Usually the fixed prefix chosen is `/usr/local`.

People install Homebrew to /usr/local (or rather, allow Homebrew to link casks into /usr/local) because it's better than the alternative — where that alternative isn't "all that stuff gets installed in a clean way instead" but rather "all that stuff makes a mess of /usr/local on its own, but now there's nothing watching it do it, so your /usr/local is now a permanent, opaque mess rather than a set of managed overlays." (Ever install LaTeX on macOS from its upstream download? Or how about calibre? PostGIS? R? They all make exactly these kinds of messes in /usr/local. At least, by letting brew install them, you can now upgrade or remove them; and it'll notice if one package's files are trampling over another's.)

Thanks for your thorough discussion of this; as someone currently migrating to macOS, I found it very helpful :).

mas is independent of Homebrew and available on MacPorts: https://github.com/macports/macports-ports/blob/master/sysut.... There's discussion on the mailing list on whether MacPorts should have a sort of "caskroom" type thing–currently it tries to avoid this except in cases where it's impractical to build from source (e.g. Java).

MacPorts is an implementation of BSD family ports package managers. I don't know much about modern ports, but when I was an active FreeBSD user, it did not install binaries, compiling the package with all dependencies instead - that is why it offers only open-source packages by definition. Darwin itself a BSD family, so I guess MacPorts were the first package manager implementation. However, proprietary applications is a common thing on Mac, unlike Linux/BSD systems, that is why Homebrew offers much wider choice of packages.

MacPorts offers prebuilt binaries for many packages these days, although you can generally install them from source if you so wish (and it will do so if you are on a release for which the package is not built).

FWIW I use Homebrew Casks to install binary stuff, which MacPorts doesn't offer, and MacPorts to install everything else. (Oops, other than stuff that is only available on the Mac App Store, for which I use mas, which will probably fatally break some day.)

I can't say I've needed to use anything outside the appstore and macports, I'm very satisfied with them. For macports you have to install the CLI tools for Xcode.

Reply on news.ycombinator.com