[__lm__]

Good job! Homebrew is, at least for me, essential for using macOS as a true *nix, and most of the changes (implemented or proposed) seem good (e.g., the ability to automatically run cleanup)

I am a little bit worried for the removal of all options that is planned for the 2.0.0 version: I have some formulae installed from source (with additional options) and I like the flexibility that they give. Hopefully the migration to an "options-free" Homebrew will be smooth and some alternative when options are needed (not requiring a lot of third-party taps) will emerge.

[ohithereyou]

> I have some formulae installed from source

Homebrew has gone out of its way to make this more difficult lately, to the point where 'brew doctor' complains when HOMEBREW_BUILD_FROM_SOURCE is set, and now it's deprecated.

Homebrew's bottle infrastructure is a tempting target if you want to get malware deployed to Macs, and as best I can tell, there is scant documentation out there about what they do to secure it. For all I know, the bottles are built on some random bozo's Mac.

The snarky side of me thinks that if build from source is discouraged then the program should rename itself to Macrobrew (as I'm sure Budwiser would sue their pants off if they used that name).

[mikemcquaid]

> there is scant documentation out there about what they do to secure it

We have private operations documentation and have had private security reviews of our infrastructure. We are actively moving away from self-hosted infrastructure this year.

[ohithereyou]

Do you have published security reviews of your infrastructure? Otherwise you're asking us to just trust you.

Note: I'm not denying that you have a stellar track record, but it would be nice to have more evidence that this is not down to luck or obscurity but is instead due to process, best practice, and understanding of risk.

[mikemcquaid]

Almost everything we have is open for you to examine (including the code, obviously). If you're not willing or able to do that: yes, you have to trust us (like you do with pretty much all software and infrastructure you don't personally control).

[_mdpn]

Yes, I know that I have to make a judgement call about whether or not to trust infrastructure I don't own, and I have made that judgement, but I'm asking for myself and others if the Homebrew project haa any additional information I and others can use to make that evaluation.

It is frustrating that you are being so opaque and dismissive. You still haven't answered my earlier question if the Homebrew project has published a summary of the results of these security reviews (I understand not posting the entire review publicly). A quick Google search did not turn up anything, which is why I am asking.

For contrast: I can find out the build process for a Debian package from their website[1]. While they do have some private operation documentation, they also publish the process by which packages get pulled into their system, built, and pushed to the mirrors[2][3]. They have documentation for how to replicate their build environment and build packages on my own[4]. This documentation is open, and I can verify packages with it as they move toward reproducible builds[5]. I understand that Debian is a much larger operation with a much longer history. I understand that it takes time to develop these things. This is not an attack on the Homebrew project or the work they do.

[1] https://www.debian.org/devel/buildd/

[2] https://www.debian.org/devel/buildd/operation

[3] https://wiki.debian.org/Teams/FTPMaster

[4] https://wiki.debian.org/BuilddSetup

[5] https://wiki.debian.org/ReproducibleBuilds

[mikemcquaid]

It is not my intention to be dismissive. I admire the work Debian has done on the above but they are a project with many more maintainers and a lot more resources. We have some documentation for our process already under https://docs.brew.sh but ultimately if it's not good enough for you we need people who are willing to step up and do the work to do so.

[mikemcquaid]

We're using analytics data to ensure that the most commonly used options (or those that don't add extra dependencies) are enabled by default. We're doing our best to make it a smooth migration (and given we're 95% of the way there already and you hopefully haven't noticed problems: I'm confident).

[mmebane]

Is there any easy way to list all installed packages for which I've customised options, and what the options I've used are?

[jslabovitz]

Could be better, but this is what I did:

    for i in `brew ls`; do brew info $i | grep -e 'Built.*with:' >/dev/null && brew info $i; done

Out of 144 formulas installed, I've only got one with an option (mpv --with-bundle). I hope the Homebrew folks will use that option as default, but I suspect they won't, and will recommend the cask instead. Which isn't really what I want, but ok.

[Hackbraten]

No need to feel dependent on Homebrew maintainers’ whims. You’re free to copy the formula, customize it the way you want, push it to your repo on GitHub, and `brew tap` it.

No need to use the Cask version if you don’t want to. If you feel stuck with the tap thing, you’re welcome to get in touch on discourse.brew.sh and we’re glad to help!

[wbl]

Have you tried Macports?

[zchrykng]

I'm seriously considering it. I have several formula installed with options and I really don't want to have to go through every formula I currently have installed and see if they decided to "bless" the options I need/want.

[Hackbraten]

You can defer that until the option is actually removed. You’ll get an error on the next upgrade. You can then reinstall without the option and decide if that’s still what you want.

If that’s not what you want, you’re free to dig up the formula with the option, and continue to maintain it on your own tap. There’s good documentation for that [1], and there are always people in our forums willing to help if you get stuck [2].

[1]: https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap [2]: https://discourse.brew.sh

[wbl]

Editing ports to add options is pretty easy and they are willing to help.