Homebrew でゾクゾク UNIX ライフ2

「Homebrew はサイコーだよ、お前ら。
　MacPorts なんかもう要らねえよ」　― @thillerson

公式サイト
Homebrew ― MacPorts driving you to drink? Try Homebrew!
http://mxcl.github.com/homebrew/
インストール手順
https://github.com/mxcl/homebrew/wiki/Installation
FAQ
https://github.com/mxcl/homebrew/wiki/FAQ

■特徴
・Mac OS Xに標準でインストールされているものは、できるだけそれを利用します
・インストール先は標準では/usr/localになります
・パッケージのことをFormulaと呼びます

■システム要件
・Intel CPU機種
・Mac OS X Leopardまたはそれ以上
・Xcode（X11も含め）
・Java Developer Update

>>86
この辺は微妙なんだよね。C/C++をしらなくったって、
フォトショやイラレとかアプリ使えりゃいいじゃんってのはその通りだし。
だからといって、プログラミングに関連しているところで
こっちが発言したことに対して「意味ない」なんて言われたら、
「だったらお前らのためにアプリなんて作らんぞ」と思ってしまったり。

そういうのがうまく言ってるのが、Macとオプソの関係だと思う。
それが>>71で自分が言いたかったこと。

ーーー　終　了　ーーー

違う話してけれ
↓

ホムブルに話すことなどない。

>>92
黙ってろ

みんな黙っちゃったよw

MacPortsからスイッチしてみた（Lion, prefix=$HOMEとした）。一点嵌ったことをメモ。
jpeg.rbがkeg-onlyになっていないのだが、これは
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
で（多分他のところでも）使われているシステム標準のlibJPEG.dylibと干渉する。これ自体は
http://tystreamer.googlecode.com/svn/wiki/FAQ.wiki
などにも書いてあるので以前からあるHomebrewに限らない問題のようだ。とにかく、これにあたるとFinderも含め、Dock以外すべてのアプリケーションが起動しなくなる。
最悪でもとりあえずの対処としてシングルユーザモードで(hbprefix)/lib/libjpeg.dylib を削除/退避すれば元に戻る。

追記DYLD_LIBRARY_PATHのせいだったかもしれない。これを設定しないようにしておくだけでよいのか？

Xcode4.2にバージョンアップしてから、gnuplotが起動しなくなった。
関連ファイルをuninstallして、cairo を --use-clang をつけて再インストール。
そうしたら動くようになった。

言葉足らずでわかりにくいから補足。

gnuplot を再インストールすると、関連ファイルも再インストールされるが、
cairo でエラーをはいて止まるので、
#brew install cairo --use-clang
で入れてから、gnuplotを入れ直したら動くようになった。

全部削除する必要はないかも試練が、cairoだけ入れ直しても
うまくいかなかったので。

速いからいいね

何このスレｗ　なんで普通の意思疎通が出来ないのが集ってるのｗ

からあげうまー

homebrewって何で/usr/localにパッケージをインストールするの？
Mac OS Xがパッケージ管理していないから、homebrewを通してインストールしたものは、（ＯＳ標準の）パッケージ管理外っていう考え方なのかな？
それとも、homebrew(自作)なだけに、/usr/localってか？

いずれにしても、パッケージ管理システムが/usr/localをいじるって気持ち悪くね？

>>102
> homebrewって何で/usr/localにパッケージをインストールするの？

Linuxとかだと、自前インストールのsoftwareはほとんど/usr/localに突っ込むよ。
だからその流儀に従ってるんじゃないの？

>>103
だから気持ち悪いという話だと思う。

むしろこうだから存在意義が

OSX的には外様とは言えパッケージ管理ツールの端くれである
homebewが使うのは変だと思う、ということでしょう。

素のOS Xでは/usr/local自体なかった気がする
ほかのOSにおけるポリシーはヨソゴトだし、そこまで毛嫌いしなくても

/sw　/opt　のほうがいいのかな

/usr/localは「えっ、NFSじゃないんだからね！」という意味なので
そのアーキテクチャー専用のバイナリーを入れるのは合ってると思う

FreeBSDのportsも/usr/localにブッこんでる

個人的には野良ビルドと分けたいので
/optとかの方が嬉しい

野良ビルドのprefix変えるんじゃダメなの？

ルート直下に /local

/opt/brew とか /brew とか作ればいいのに、
なんで既存のディレクトリにインストールしようとするのかねぇ

ルート直下に余計なもん作るほうが問題だろ(；´Д`)
色んなもの使いたいなら homebrew よか macports 向いてる。

/usr/local/binに入るのはバイナリそのものじゃなくてシンボリックリンクだからいいんじゃね？

Cellar..相当酒飲みだw

自家製だぜ。

確かにその気持ち悪いって感覚がな
最初はいいと思ったんだけど
入れる時速いだけで裾野も狭いし
やっぱり/opt下で完結した方が
て事でportsに戻ったわ

>>115
ルート直下に作ると何が問題になるの？

macがパッケージ管理を標準でサポートしないのがいけないんだ
Apple流の考え方で、ユーザにとって最も良いパッケージ管理はAppStore & ソフトウェアアップデートってことなんだろうし、AppleとしてはAppleが審査を通していないアプリやコマンド類の流通はさせたくないんだろうから。

じゃあどのパッケージ管理システムがいいのか。
Portageでしょう
Portage以外のパッケージ管理システムは、ゴミとまで言わないけど、機能が似たりよったりな上にメンテが中途半端だったりする、Portage以外で選ぶならhomebrewが丁度いい。

macportsは悪くないけど、/optは独立したパッケージを入れるところ。
OSが提供するパッケージと同様のパッケージや、その最新版・開発版まで何でもかんでもoptに入れるのは始末が悪い。
わざわざMacPortsのためにパスを書き換えたりしなきゃいけないから。せめてalternativesがあれば少しはマシかもしれないけど。

homebrewは、rubyistか、自前主義の人、macに標準で組み込まれているコマンド類(ld, gcc等々)が気に入らない人にとってはいいかもね。
Formulaが書きやすいからパッケージの少なさが気にならないし、標準のFormulaがどのビルドオプションを使っているのかすぐに分かる手軽さがいい。

１行しか読んでないけど
なんか気持ち悪い

ルート直下にソフト特有のディレクトリを作るのって、
なんかWindowsみたいでヤな感じ。

/opt は独立アプリを置くところなのは浸透してるし
/opt/local だから直下じゃないけど、なんで local なんてパスにしたのかが謎。

>>121
Formulaの書き易さはホントにありがたい

>>124
/opt/binとかはNFSだから。

>>126
そういう意味じゃないだろ。
/opt/ports なんかにしなかったのはなぜって質問じゃないの？

/opt/localだから別に良くね？

うん。

homebrewって/usr/local/Cellarにソフト毎、バージョン毎にディレクトリが作られるんですね
macportsの場合、普通/opt/localに１回パス通せばport installやport upgradeを後からしても
そのまま使えますが、homebrew使ってる人は新規インストールやアップグレードする度に
パス通してるんですか？

悪意は無いつもりなんだけど、パスの話以外に有用なネタとか無いの？

>>130
パッケージはCellarにインストールされるけど、そこから/usr/local/binにリンクが貼られるから、/usr/local/binに対して１回パスを通す

>>131
ではネタを

homebrew経由で何らかのパッケージをデバッグビルドして、さらにソースコードを保持しておくにはどうしたらいい？
homebrewって展開したパッケージを/private/var/tmpに置くんだよね、、
/usr/local/srcだと嬉しい

>>132
あーなるほどそういう事か、ありがとう

たしかにパスの話するやつって何目的で homebrewつかってるんだろうね。

ところで、 brew doctor のメッセージいつのまにか変ったね

brewに欲しいパッケージがないと判明した場合、どうするか。
Finkでバイナリを探す。
tar.gzを入手して、,/configure　--prefix= .... で作る。
大仰ながらMacPortsに鞍替え

configureするスキルがあるならforkしてFomula化すればいいんじゃねーの?

>>136
configureするスキルって・・・
だれでもあるようなきがするw

./configure --help

HOMEBREWかっこいいですね！気に入りました！

brew install中のプロセスを安全に停止させるにはどうしたらいい？
出社前にpython3を試そうと思ったんだけど、いろいろ間違ってgccをインスコしちゃって、インストールが終わるのに半日ぐらい掛かりそうなんだ。

^c

test

なぜFinkが潰されたと思ってんだよ。教祖が死んでもMacが
Linuxみたいになる事は許されない。
オープンソースをMacが使う事はあっても、それはあくまでも脇役として
存在は抹殺されていなくてはならないのだよ。
だからMacPortsのような囲われた範囲でしか利用しては
ならないのさ。消されるのが目に見えてるな。

なんなのいきなり

電波受信

Homebrew入れてみた。
Xcodeがないとおこられた。
Xcodeデカ過ぎ。adslだから時間かかりまくり。

jdをビルドしたいのですが、libtoolizeがないので進めません。
libtoolをbrewで入れることはできませんか？

と思ったら、libtoolは/usr/binに入ってました。
うーん、なんでlibtoolizeないんだろう。

わけわかんねえから、linuxからコピってきた

/usr/bin/glibtoolize ない?

OSXのlibtoolはGNUのlibtoolとは別物…

ほうglibtoolizeか。autogen.sh書き換えて通してみる。

configureできた。gtkmm入れてなかったからインスコ中。

iconvがリンクできなかった。もう少し格闘してみる。

/usr/libのiconvは・・

一応、ビルドできたけど、いろいろトラブってる。

fontconfigでデフォルトフォントを日本語にできなかった。
.fonts.confとか/usr/X11/lib/X11/fontconfig/conf.dに
設定してもSansのデフォルトにならなかった。
とりあえず、.gtkrc-2.0とアプリでヒラギノを直に指定した。

あと、書き込みができない。これはjd自体の問題みたいなので、ほかでやってみます。

ところで、

>>155
とりあえずlibiconvでビルドしたんだけど、
/usr/libのほうはiconvは地雷ってことでいいの？

/optがーとか騒ぐ割に/usr/localの意味も考えずに色々インストールするよね

/usr/localの意味をどうぞ

田舎出身者

皆さんhomebrewでlibtiffってインストールできますか？
なんかエラーが出てしまうんですがこれが自分だけのエラーなのか知りたいです

>>160
インストールできてるよ

おせっかいだけど、自分だけのエラーなのかどうかを識別するのが目的なら、エラーの内容を見せたほうがいいと思うよ。
だって、他の人もエラーが出るけど、その内容があなたのエラーと同一ではない可能性があるでしょ
＃悪意は全く無いよ！

>>161
すみません、なんか忠告にも気を使ってもらって

エラーは下記URLの通りです
http://pastebin.com/rAXfynbW

264行目にあるhttps://github.com/mxcl/homebrew/issues/9965に、
--with-apple-opengl-frameworkや--enable-cxxを付けてみろと書いてたので
/usr/local/Library/Formula/libtiff.rbに書き足してsudo brew install libtiffやってみたんですが
同様のエラーが出てしまいます

>>162
すまん、今レスを読んだ

http://pastebin.com/って便利だね！

175行目 Undefined symbols for architecture x86_64:
225行目 ld: symbol(s) not found for architecture x86_64
ってあるから、libjpegがi386 (32bit) architecture onlyでビルドされている

/usr/local/lib/libjpeg.62.0.0.dylib
って表示されているから、homebrew以外からlibjpegを入れてない？？
もしくはlibjpegのバージョンが古くない？
homebrewからインストールされるlibjpegの最新は「8d」だよ

もしhomebrewからインストール済みなら、一旦libjpegをアンインストールしてから、インストールし直してみて。upgradeでもいいけど。

もしソースコードからconfigure & makeで直接インストールしたなら、削除するファイルを特定しなきゃいけない。
ファイルの作成日付であたりを付けるか、libjpegのソースから、prefixを別なtmpディレクトリにしてconfigureして、ビルド・デプロイすれば生成されるファイルがわかる。

もし、何らかのpkgをインストールしたときに紛れ込んだなら、pkgutilを使って地道に犯人のpkgを割り出して、該当しそうなファイルを抽出。

もうどうにでもなーれ、というなら、homebrewから直接最新のlibjpegをインストールしてみたらどうだろう。

それでもダメなら、--verboseオプションで詳細なログを貼りつけて、誰かに見てもらう

/usr/local以下に何かをインストールする場合は、インストールするものをきちんと把握しておかないと、homebrewと競合して酷いことになるよ。
特にpkgは勝手にいろいろとインストールしてくれるから、事前にpkgを解凍して中身をチェックしておくのが吉。

>>162
いい忘れたけど、libtiffをUniversal Binaryでインストールしたい、ということなら力になれないなぁ

https://github.com/mxcl/homebrew/issues/9965
で議論されているけど、ashgtiさんが--universalオプションを付与したFormualをリクエストしたけど、adamvさんに突っ込まれてからよく分からない状態のまま放置されているね

こっちでもlibtiffのconfigureをざっと見たけど、Universal Binaryにするためのオプションが見当たらないから、Makefileを解析しないとどういう条件でUniversal Binaryになるかが分からない

>>163-164
homebrewでインストールしていたlibjpeg(8d)をアンインストール後、再インストールせずに
sudo brew install libtiffしてみるとあっさりうまくいきました！

質問前からlibjpegが何かおかしいのかなと思って再インストールを繰り返してたんですが
アンインストールしてからlibtiffのインストールを試みてはいませんでした

本当に丁寧な回答ありがとうございます
２ちゃんでここまで親切にされたのは８年くらいやってて初めてです

>>165
そいつは良かった

ちょっと遅いかもしれないけど、sudo付けなくていいよ
homebrewインストール時に、インストーラーが権限を書き換えているから
もしsudoが必要な状況に遭遇していたら、pkgが権限汚染をしている可能性が高いから、今すぐ直したほうがいい

/usr/localを含めた/usr/local以下のディレクトリに対して、
　chownで所有者を自分にする
　chgrpでグループをadminにする
　chmodでg+rwxする
を適用するんだ
pkgの都合で、/usr/local/hoge_pkgみたいに、/usr/local以下にパッケージ専用のディレクトリをきっているものに関しては、そのままでいい。homebrewの管轄外だから。

んじゃおやすみ

/usr/local を使うべきではない理由
https://trac.macports.org/wiki/FAQ#defaultprefix

Homebrewのことよく知らない人間だが、>>166読んでふと思ったんだけど
/usr/localをユーザ権限にしてしまって大丈夫なの？
これってsudoうつのがめんどくさいというだけの理由？

なにが駄目だと思って心配してるの？

トロイの木馬を仕込まれる可能性は高くなるとはいえるが、
そもそもパッケージシステム使ってる時点でなあ…

せっかくのUNIX環境なのに、sudoを避ける為だけに本番系と権限周りを大きく変えるのは勿体無いとは思う

sudo 入力避けの為なわけねえだろ

https://github.com/mxcl/homebrew/wiki/FAQ

Homebrew側がsudo is badと思っているからやってるんじゃないの？

いいかい？
HomebrewのFormulaはRubyを使って「有志によって作られる」んだ

もし、どこの馬の骨ともわからない奴が、Formulaに重大なバグや>>170の言うようにトロイの木馬を仕込んだとしよう。
そのFormulaをインストールした多くのHomebrewユーザが、危険にさらされるのは目に見えているよね。

だからユーザ権限の範囲でFormulaをインストールするようにして、システムを守っているってわけさ。

/usr/localがroot権限より脆弱（？）なユーザ権限になると、外部の脅威にさらされるんじゃないか、っていう危惧は分かる。
けど、/usr/localなんてシステムに影響しないんだ。もともとMacに入っていないし。
つまり、セキュリティの重要度で言ったら、
　システム＞＞＞/usr/local
ってわけだよ。

公式に登録されたFormulaは安全だから大丈夫だって？
冗談言うなよ、どこにそんな保証があるんだい？'`,､('∀`) '`,､

アメリカンな人がいる

それなら /opt/homebrew とかでやればいいのに

>>174
/usr/localは、ディレクトリ自体はないけど、
/usr/local/binはPATHに最初から入っちゃってるんだよね

>>177
それの何が問題なの？
不正なプログラムが/usr/local/binにあって、パスが通ってて、誤って実行されたとしても、ユーザ権限に変わっているんだから、システムへの悪さは出来ない、ってことじゃないの？？

システムに悪さできなくても「rm -rf /Users/username」みたいなことは可能なわけで。

>>174
homebrew用に書き込み権限付与したログイン不可ユーザ作成して、そのユーザにsudoして使うんじゃ駄目なのかな？
性質上、rootのsudoを使用するのが危険なのはわかったけど、
だからといってstaffに書き込み権限付与するのはそれはそれで危険だと思う
いきなり通常ユーザに権限渡すんじゃなくて、homebrewを使用することを意識した権限管理があった方がいいと思うんだけど

あと、/usr/localはアプリの独自インストールで使用される以上
通常の/usr/localの権限で使用できないのなら、やはりディレクトリは分けたほうがいいのでは？

>>178
PATHに.を含めてはならないという掟と同根だと思うが

結局何がベストなんだ？
homebrewはイケてないってことか？

>>179
個人端末としての用途のほうが多いMacだと、システムに悪さをされるより、ユーザ環境に悪さをされる方が厄介だよね。

>>180
homebrew用のアカウントを作るのは賛成だね。
日常で使うユーザアカウントでhomebrewの権限を書き換えると、そのユーザのディレクトリに悪さができちゃうし、かといってルート権限だと、もっと悪いことができるからね。

セキュリティと利便性のバランスの問題についても、
brew upgradeが
sudo -u hoge brew upgradeになるだけだから、個人的にはOKだと思う。

＞だからといってstaffに書き込み権限付与するのはそれはそれで危険だと思う
staffに権限を付与じゃなくて、ユーザに権限を付与、ってことだよね。

ちなみに、パスワードを要求してインストールするタイプのパッケージインストーラーの話だよね？それなら、インストールで/usr/localを使用するとき、使用するディレクトリを勝手にroot/wheel権限に書き換えちゃうはずだよ。
$ ll /usr/local
drwxr-xr-x 1 sage staff 123 1 11 23:59 bin/
drwxr-xr-x 1 root wheel 136 1 11 00:00 hoge_packages/
みたいな感じで。
だから、homeberwが使っているディレクトリと、何らかのパッケージが使っているディレクトリが同じだと、権限がかち合って、おかしなことになる。これってhomeberwがイケてないってことだよね。

>>181
何を言いたいのか分からない


homebrew使わないほうがいいのかな・・・。

マジレスするとお前みたいなやつは使わない方がいいよ。
セキュリティの気の使いかたが偏りすぎてる。

実用性にそくしたバランスを自分で納得しながら環境構築できないなら
App Store のアプリケーションだけ使ってろよ。

>>182
181の意味が分からないのに半端に知識はありそうなところが何ともいえないな…
Mac以外の*NIX系のOSは触ったことがないのかな？

ちょっと脱線しそうだから、
　/usr/local以下の権限は、root/wheelがいいか、USER/adminがいいか、
っていう点に絞って過去レス読んでまとめてみた。

Aパターン：/usr/localはUSER/admin権限にする
→利便性重視、公式(mxcl)やalt(adamv)のFormulaのみをインストールする場合等
→一般ユーザ向け
メリット：普段使うユーザアカウントのみ管理すればいい、システムへの影響が少ない、sudoしなくていい
デメリット：テストすらしていないFormulaをインストールしたときは、ユーザディレクトリを破壊されるかもしれない
（ユーザディレクトリをいじるFormulaなんて無いだろうし、自分で選んでパッケージを入れるんだから不正コマンドなんて入らないと思うけど）

Bパターン：/usr/localはHOMEBREW_USER/admin権限にする
→セキュリティ重視、開発中のFormulaをテストする場合、マルチユーザ環境の場合等
→Homeberw/Formulaのデベロッパー向け、特殊用途向け
メリット：権限が異なるので、ユーザディレクトリへの影響が無い、システムへの影響が少ない
デメリット：Homebrew用のユーザアカウントを管理する必要がある、Formulaインストール時にsudo -uする必要がある

A・Bパターン共通：
pkgインストーラは、pkgutilを使って/usr/local以下にインストールされないかチェックしてからインストールする
→権限汚染の回避、/usr/localの管理のため

Cパターン：/usr/localはroot/wheel権限にする
→利便性重視、pkgインストーラーをよく使う場合等
→/usr/localの管理がめんどくさい人向け
メリット：pkgインストーラーとの権限衝突が起こらない
デメリット：Formulaによってはシステムへの影響があるかもしれない、Formulaインストール時にsudo -uする必要がある

個人的には、Cパターンはおすすめしない。
/usr/localを管理していないと、pkgインストーラによってコマンドやライブラリが別バージョンに上書きされてごちゃごちゃになる可能性があるからね。
それがイヤならhomebrewを使わないか、インストール先を/usr/local以外に変えたらいいと思う。（そこまでするならMacPortsを勧める）

オレはやっぱりAパターンでいいや。

異論があればどうぞ。

>>184
で、結局何が言いたかったんでしたっけ？

カレントディレクトリをPATHに指定すると、ヘンなところにそれっぽい名前の不正コマンドが仕込まれて意図しない処理が実行される可能性があるから？
それとも、LD_LIBRARY_PATH(Macは違うけど）の話で、ライブラリの話を混ぜてる？Macは基本的にライブラリに絶対パスが含まれるよ。他の*NIXと違って。

/usr/localの権限の話とどう関係するのか本当に分からない。オレが知らないLinuxの常識がそこにある気がする
もやもやして眠れないんだぜ

homeprew で pdftkがインストールできません。
環境はcorei7、lion

$ brew install https://raw.github.com/gist/1963857/ae35a570231aae929927d5c895e46059ef027264/pdftk.rb
とすると、
Error: No available formula for gcc (dependency of pdftk)

/usr/bin/gcc
はあるんだけどな？

$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


アドバイスください。

lion から gcc が llvm-gcc-4.2 になってるから、
前の xcode から gcc4.2ひっぱってそっちよみこんでみれば

>>188
brew tap adamv/alt
brew tap homebrew/dups
みたいな感じでリポジトリを追加するか、
Hombrew/dups のリポジトリにある gcc Formula を --enable-java オプション付きでインストールしておけば良いと思う。
Xcode とかのバージョンによっては --use-llvm オプションもいるかも。

tap と untap コマンドが Homebrew 0.9 で追加されてて、リポジトリが追加できるようになった。