Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

El Capitan and Homebrew

github.com

Post reply on HN
Print view View original

241–250 of 298 posts

Re: El Capitan and Homebrew

#241

Post by mzs »

tptacek wrote: post #215
OJFord wrote: post #205

Earlier quoted context omitted.

> it should follow common unix standards Isn't /usr/local? > or at least fit in with OSX It did - before now /usr/local was available unprivileged with ownership. > rather than require a hack It only needs that now, since requirements to "fit in with OSX" have changed. That's not Homebrew's fault - they need a fast solution. Kudos in my book for responding before it's a problem.

No, /usr/local is normally 755 root:root (or whatever the effective equivalent is). Homebrew wants it to be 775 root:admin, so that users with the admin bit can write to it. That's not standard. People keep writing here as if El Cap removes /usr/local entirely. It does not. /usr/local is there by default. You only have to go into recovery mode if you've somehow removed it yourself.

quesera's reply points-out just how bad it is, but even for just 775 root:admin I would have to use sudo (plus edit the sudoers or /usr/bin/login -p first) anyway:

  $ /usr/bin/env -i /bin/sh -c \
    'id | grep -lw admin >/dev/null && echo admin || echo non-admin'
  non-admin
The problem is I have no problem using sudo, but homebrew does (like it wants make all to happen as me).

Re: El Capitan and Homebrew

#242

Post by neverpanic »

Scarbutt wrote: post #223
mapgrep wrote: post #214

Earlier quoted context omitted.

Just FYI anyone can download XCode from the App Store, it doesn't require a "dev login". (Agree it would be nice if MacPorts only required the XCode Command Line tools like homebrew, it would be one less download.)

I was going to try macports but the XCode download turn me off, why it can rely only on the command line tools?

It can, in theory. In practice, there are some ports that actually need a full Xcode installation to build, and those would just fail without Xcode.

In an ideal world, there would be a dependency declared on Xcode for all those ports so MacPorts would work with command line tools only and fail gracefully whenever Xcode is required. However, that is currently not the case because nobody implemented an easy and automated way to tell whether a port will build fine without Xcode.

Re: El Capitan and Homebrew

#243

Post by mzs »

tptacek wrote: post #194
DannyBee wrote: post #152

Earlier quoted context omitted.

A. There is no real standard here B. Apple doesn't bend, period. They don't actually care whether the use is appropriate or inappropriate. C. Blaming this on homebrew is hilarious Remind me again why i should need to reboot into recovery mode to create a directory?

You need to boot into recovery mode to create /usr/local (or to disable SIP altogether) because /usr is immutable, so that code executing under an admin account can't inject itself into binaries (or into PATHs) under /usr. I use Homebrew and will probably keep doing that because Homebrew is really convenient and just generally works better than MacPorts for me, but what Homebrew is demanding --- ownership over /usr/l…

And I contend that homebrew did not want to used ~/.homebrew because that would mean modifying files to add it to PATH and be additional testing for people that write recipes.

Re: El Capitan and Homebrew

#244

Post by teacup50 »

mmastrac wrote: post #177
robbles wrote: post #173

Earlier quoted context omitted.

The reason I switched to HomeBrew, after attempting to use MacPorts for several years, was that the formulas all actually worked and resulted in installations that weren't horribly broken and/or reliant on 10 different additions to my PATH and environment variables. Homebrew may have some questionable policies, but at least it works well and has recipes that successfully compile. It also tells you why recipes aren't…

Ditto. And Homebrew's policy of avoiding installation of built-in packages by default means that you don't accidentally break your whole system when MacPorts shadows a critical core package.

I can't fathom how MacPorts could ever break your whole system.

- MacPorts' /opt/local is not in any of the default system paths.

- MacPorts uses sandboxing to ensure that builds can't stomp anything outside of /opt/local

Re: El Capitan and Homebrew

#245

Post by ashark »

robbles wrote: post #173
mapgrep wrote: post #163

Macports, meanwhile, continues to work quite well because it 1. places packages in /opt and 2. has always installed via sudo. Macports just has a much more robust philosophy of building its own universe largely separate from OS X, and only rarely impacted by system updates. The downside is that it takes forever to install the first few packages. Homebrew offers a much faster initial install because it leans on OS X l…

The reason I switched to HomeBrew, after attempting to use MacPorts for several years, was that the formulas all actually worked and resulted in installations that weren't horribly broken and/or reliant on 10 different additions to my PATH and environment variables. Homebrew may have some questionable policies, but at least it works well and has recipes that successfully compile. It also tells you why recipes aren't…

I switched after having to blow away my Macports directory and start over four times in the first year I used it due to unrecoverable levels of brokenness. ~4 years of HomeBrew later and the worst I've had to do is `chmod`.

Re: El Capitan and Homebrew

#246

Post by jrochkind1 »

baldfat wrote: post #112
dyladan wrote: post #102

Earlier quoted context omitted.

I don't see anywhere in there where it says you should take ownership of /usr/local

That is why I said I searched and got the standard for the person who said "certainly it isn't the standard." We have the ultimate resource to know the answer to any question that does have an answer. I gave this down voted "I googled it for you" because people need to just look up what the Standard is and than speak from a position of knowledge and not some vague non-answer. For the still lazy the Unix File Hierarch…

Confusingly, it also says:

> The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.

> Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.

http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHI...

It says "The /usr/local hierarchy is for use by the system administrator when installing software locally."

That seems to kind of conflict with what you quoted "Large software packages must not use a direct subdirectory under the /usr hierarchy.", unless they mean a vendor-specific directory rather than "/usr/local".

I dunno, all I can say is that in my experience on various unixes, it is a "common unix standard" to install software that is not controlled by the OS package manager to /usr/local. I don't interpret "common unix standard" as "FHS" though -- if you mean FHS, say FHS. To me "common unix standard" just means "something that is commonly done on unix". And installing locally-installed (not using OS distro) software to /usr/local is pretty commonly done, as many people can attest. That's why homebrew chose it, they didn't just make it up.

Re: El Capitan and Homebrew

#247

Post by mzs »

DannyBee wrote: post #168
quesera wrote: post #164

Earlier quoted context omitted.

A. /usr/local has never ever been writable by a nonprivileged user. Every standard that exists, including the principle of least surprise, is emphatic on that point. The security implications of "any other way" are massive. B. If Linus or the FHS changed their ways in this, there would be outrage. It's inappropriate and just plain dumb. [edit: I shouldn't have said "dumb", please replace with "in violation of all gua…

A. Single user systems are not the same as server systems, and plenty of single user systems have had the equivalent of /usr/local as writable. If you want to argue this security is worth it, that's a different argument. I suspect most people who just want to get shit done are going to find it a huge pain in the ass. You can also argue these people are stupid. As for standards, vendors follow FHS and friends exactly…

I see what you are saying but please step back and take a wider view for a moment.

Even assuming OSX is a single user system (which is arguable), it is 2015 and should that single user be able to accidentally damage /usr/local? I think not, that by today an OS should help protect you from broken postinstall script or what not.

Moreover please think about this: homebrew is not wanting /usr/local/ root:admin but instead /usr/local/ `/usr/bin/whoami`:admin.

Further even on our laptops where there is just one user, I use a non-admin user. I have no problems using FUS, GUI prompted temporary admin permissions, or /usr/bin/login -p and sudo day-to-day, but homebrew has a problem with sudo.

Apple SIP has no problem with /usr/local/ 0:0 but homebrew does. Because of shortcuts homebrew has forced a number of poor decisions on it's users.

Re: El Capitan and Homebrew

#248

Post by mmastrac »

ashark wrote: post #245
robbles wrote: post #173

Earlier quoted context omitted.

The reason I switched to HomeBrew, after attempting to use MacPorts for several years, was that the formulas all actually worked and resulted in installations that weren't horribly broken and/or reliant on 10 different additions to my PATH and environment variables. Homebrew may have some questionable policies, but at least it works well and has recipes that successfully compile. It also tells you why recipes aren't…

I switched after having to blow away my Macports directory and start over four times in the first year I used it due to unrecoverable levels of brokenness. ~4 years of HomeBrew later and the worst I've had to do is `chmod`.

Having used both, I agree. Homebrew is just better. I have not had to start from scratch with Homebrew. I had to start from scratch multiple times with MacPorts once I had installed a critical mass of conflicting packages.

Re: El Capitan and Homebrew

#249

Post by teacup50 »

ashark wrote: post #245
robbles wrote: post #173

Earlier quoted context omitted.

The reason I switched to HomeBrew, after attempting to use MacPorts for several years, was that the formulas all actually worked and resulted in installations that weren't horribly broken and/or reliant on 10 different additions to my PATH and environment variables. Homebrew may have some questionable policies, but at least it works well and has recipes that successfully compile. It also tells you why recipes aren't…

I switched after having to blow away my Macports directory and start over four times in the first year I used it due to unrecoverable levels of brokenness. ~4 years of HomeBrew later and the worst I've had to do is `chmod`.

If you've been using Homebrew for 4 years, you probably missed MacPorts' adoption of binary packages, automatic detection+repair of broken library linking, sandboxing of builds, etc.

That's resolved all of the fragility (and heinous build times) that previously existed.

Re: El Capitan and Homebrew

#250

Post by tptacek »

mzs wrote: post #243
tptacek wrote: post #194

Earlier quoted context omitted.

You need to boot into recovery mode to create /usr/local (or to disable SIP altogether) because /usr is immutable, so that code executing under an admin account can't inject itself into binaries (or into PATHs) under /usr. I use Homebrew and will probably keep doing that because Homebrew is really convenient and just generally works better than MacPorts for me, but what Homebrew is demanding --- ownership over /usr/l…

And I contend that homebrew did not want to used ~/.homebrew because that would mean modifying files to add it to PATH and be additional testing for people that write recipes.

And that's totally fine, and I let Homebrew own /usr/local too. What I'm not going to do is freak out when a totally sane and useful security feature breaks that install mode, especially when I could, if I cared that much about convenience, just take 30 seconds to disable the security feature.
Post reply on HN