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

知ったかは黙れよ

>>83
なら、お前の知っていること一つでも語れよ。
llvm や clang くらいは当然使いこなしているよなw

>>83
2ch文化 = 知らないやつは叩く
OSS文化 = 知らないことを補い合って向上する
これが本質的な違い。

>>85
いいこと言った

恐ろしいまでに内容のないレスの応酬

2ch で煽り耐性の無いやつって中学生以下だろ…

>>87
自分が理解できていないだけだろ。
Lion対応なんて、clang周り以外の何ものでもない。
それがわかっただけで価値がある人間はいくらでもいるが、君はその中に入っていないだけ。
まぁ、Homebrewユーザーはそんなものか。

>>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 のアプリケーションだけ使ってろよ。