Both Homebrew and MacPorts are "rolling release" package managers

[bobsummerwill]

From @bobsummerwill on January 8, 2016 22:21

Both Homebrew and MacPorts are "rolling release" package managers, which means that it is impossible for us to build a 100% reliable OS X delivery mechanism on top of them. We will have build breaks.

See Tweet thread #1 and Tweet thread #2 for more conversation on this topic. Essentially the model is that you ask for a particular package to be installed, and you are going to get the latest version at the time when you ask.

Homebrew has no mechanism for saying brew install package version in a repeatable form. You cannot ask for a specific version up-front, and different end-users will get different versions depending on when they ran the build process.

This limitation is not something which we can fix, though we can reduce the impact by turning some external dependencies into git sub-modules. That won't be a utopia, though. Alternatively, we can add external packages to our Homebrew tap to achieve the same kind of result, though then the "fix" will be OS X only, rather than us having solving that versioning lock-down consistently across all our platforms.

I am just logging an issue here to note the elephant in the corner.

Copied from original issue: ethereum/webthree-umbrella#118

[bobsummerwill]

From @tdsmith on January 12, 2016 6:9

IIRC the tweet you link for "fundamentally unstable" isn't totally correct, but your fundamental concern that Homebrew is a rolling-release package manager is true.

If you're interested in maintaining formulas for some part of your dependency tree inside your tap, that's something you can do to isolate the packages you distribute from changes to the formulas Homebrew distributes. homebrew-julia is one example of this strategy.

[bobsummerwill]

Hey @tdsmith!

You mean that information within the thread of tweets is incorrect, or me categorized that tweet content to mean "fundamentally unstable" isn't an exact match to the assertion? If the latter, then yes, that is fair. Let me re-wordsmith.

Yes, "Homebrew is a rolling-release package manager" would be a slightly nicer way of saying what I mean, which is that there is no guaranteed way of getting repeatable results with a normal use-pattern of Homebrew, because that is not Homebrew's fundamental model.

So, we could replicate all (or a subset) of external packages in our own tap? I guess that ends up being equivalent-ish to what the "versions" support is doing, eh, but it seems a pretty antithetic approach? And perhaps that is the root-cause of the "deprecated-ish" status for "versions" support, living in the boneyard?

Well thanks for the feedback.

[bobsummerwill]

Hey @tdsmith - So I've edited that initial comment above. Do you think that is now correct and fair? Many thanks!

[bobsummerwill]

From @tdsmith on January 12, 2016 7:36

I wasn't offended but I think this is clearer; thanks!

Just to recap, using the brew versions command to rescue old formulas from git history is deprecated; the homebrew-versions tap (which is, I think, morally similar to maintaining your own dependency tree) is not.

[bobsummerwill]

So, @tdsmith, the homebrew-versions tap might, in this example, have a cryptopp562 formula, if somebody else needed it, or if we requested it, so we could do something like:

homebrew install cryptopp562

which would be equivalent to the:

homebrew install cryptopp 5.6.2

command which we would really like, but done in a way which "works with the grain" for Homebrew?

Or, we could add a formula to our OWN tap for that, which would be easier because it is under our control, but that would result in:

homebrew install cryptopp

Hitting our formula ahead of the "global" one? Is that right? Thanks!

Aha - hearing that "brew versions" was resurrecting old formulas makes everything make sense now. That approach would ACTUALLY have been closer to what I would like, but I can understand why it would be deprecated, because it runs counter to the whole idiom.

[bobsummerwill]

From @MikeMcQuaid on January 12, 2016 11:44

Alternatively, we can add external packages to our Homebrew tap to achieve the same kind of result, though then the "fix" will be OS X only, rather than us having solving that versioning lock-down consistently across all our platforms.

This is the correct approach if you want to ensure all your dependencies have specific versions on OS X. If you want to do this cross-platform I'd recommend you vendor all your dependencies either in-repository or using Git submodules.

[bobsummerwill]

From @MikeMcQuaid on January 12, 2016 11:47

As to why Homebrew does this: it's extremely hard to run a build-from-source distribution and across multiple OS X/Xcode/compiler versions and ensure things are consistently buildable from source. If/when we have binary packages for everything it may be easier to track binary package dependencies by the versions of the dependencies they depend on. Even then, though, as we do not design old versions such that they can necessarily be installed side-by-side: this would be a lot of work.

[bobsummerwill]

Thanks for the insight and confirmation, @MikeMcQuaid!