macOSでのビルドをHomebrewが吸収する理由
今回は、Homebrewについて話していければなと思うんですけど、Homebrewといえば、macOSを使っている開発者だったら、大体が抑えられているようなパッケージ管理ツールですよね。
そうですね。Macだと大体の人は使っていると思うんですけど、UNIX系のソフトウェアを自分でコンパイルしようとすると結構大変なんですよね。
ソフトウェアごとにビルド方法が微妙に違ったりとかして調べないといけないし、あとLinuxと違ってこのオプションをMacだったら使わないといけないとかもあったりするし、とにかく結構いろいろ違うんですよ。
なので、そういうのをいろいろ吸収して頑張っているのがHomebrewだったりするので、Homebrewを通してMacで開発するにはみたいな話ができたらなと思っています。
はい。じゃあ早速話していければなと思うんですけど、まずはUNIX系のツールでMacでコンパイルしようとすると結構大変みたいなところから話していければなと思いますね。
そうですね。結構大体のツールはC言語とかだとドットコンフィギュアしてメイクしてメイクインストールってやるのがLinuxだったらよくやるやつかなと思うんだけど、
Macってそれで単純に動くこともあるんだけど、動かないこともあるんですよね。
そのメイクとかでインストールしてビルドしてみたいないうのは基本的なLinux向けに用意されていることが多いからって感じですよね。
そうですね。Mac、Linuxと全く一緒ってわけじゃなくて、例えばGCC、CのコンパイラーとかもLinuxだとGCCだけど、MacだとデフォルトだとCRANっていう別のやつだったりもするし、
あとシステムに入っているヘッダーとかライブラリとかもLinuxとそのディレクトリの場所が違ったりとかもするので、結構微妙に違うみたいな感じなんですよ。
なので、コンフィギュアしても上手くライブラリ見つけられないとか、いろんなトラブルが起こったりとかするんですよね、Macでやろうとすると。
若干違うからちょっとめんどくさいところがあるっていうところですね。
そうなんですよね。若干違うんですよ。なのでLinuxと同じ感覚では基本的には使えない。
で、その辺をそのソフトウェア一個一個にこういう風にコンパイルしたらいいよみたいなのを管理しているのがホームブリューなんですよね。
Mac向けにビルドするんだったらこうしてよねみたいないうのをまとめているのがホームブリューってことですね。
ホームブリューのメイクのファイルみたいなところがそういったところを吸収しているみたいなイメージなんですかね、ホームブリュー側の。
そうですね、例えば何かUbuntuだとアプトってやつがあってアプトインストールで何かいろいろソフトウェア入ると思うんですけど、
結構何かそのアプトと比較されるのかなと思うんだけど、何か自分の中ではアプトとは全然違っていてホームブリューって。
ホームブリューは物によってはそのコンパイル済みのバイナリーダウンロードしてるケースもあるんだけど、
基本的にはそのMacでのコンパイル方法が書かれている設定ファイルみたいなのを、
まあそれRubyなんですけど、その設定ファイルを配っていて、その設定ファイルに書かれている通りソースコードをダウンロードしてコンパイルしてみたいなのをやってるんだよね。
なるほど、じゃあ逆に言えばアプトとかの場合は基本的なビルド済みのものをダウンロードしてくるに特化されてそうな感じなんですかね。
そうですね、アプトの方はその依存関係とかを解決しつつ、基本的にはコンパイル済みのバイナリーがダウンロードされてくる、
でその後設定ファイルを配置するみたいなことをやるのがアプトなんですけど、ホームブリューはもうそういう感じじゃなくて、
もうコンパイルする、でそのコンパイル方法が書かれているっていう感じですね。
じゃあビルドスクリプトなんですね。
そうですね。
多分ブリューの方は。
そうですね、なのでその辺でそのUbuntuのアプトとかとは全然使い方が違うっていうところですね。
確かに、ちょっとなんでホームブリューはビルドを前提にするのかみたいなとか若干気になるところではありますけど、
なぜかそのバイナリーではなくてっていうところで。
一部、もともとはなかったんですけど、最近はバイナリーも一部有名なやつとかだったらバイナリーダウンロードしてるケースもあるんですけど、
これってなんかホームブリューに限らずだと思ってて、
例えばそのGoとかNode.jsってそのコンパイル済みのバイナリーがすでに用意されていて、
それをみんなダウンロードして配置してるだけなんですよね、基本的に。
けど例えばRubyとかPHPってソースコードしか配布されてなくて、
コンパイルするのは各ユーザーなんですよね。
もちろんRubyとかPHPってアプトとかでも入るんだけど、
アプトとか入るやつはコンパイル済みなんだけど、
それはそのPHPとかRubyの人たちがやってるんじゃなくて、
Ubuntuの人たちとかDebianの人たちが用意してくれてるものなんだよね、それは。
なるほど、そのツールの公式が用意しているバイナリーではなくて、
各OSの管理、ディストリビューションの管理のところが、
このRubyだったらこのRubyのビルド済みのものを使ってくださいね、
みたいな形で配布しているっていうことが多いって感じですかね、イメージとしては。
そうですね。さて何かっていうと、
基本的には正直お金があるかどうかみたいなところが結構大きくて、
GoとかNode.jsってやっぱり開発元がすごい器用だったりとかしてしっかりしてるので、
コンパイル済みのバイナリーを配れる協力があるんだけど、
RubyとかPHPって基本的にはボランティアベースなので、
そんなリソースないんですよね。人的リソースもないし、
あとマシンのリソースとかも多分ない。
なのでそもそも用意してくれって言っても対応が難しいんですよ、開発体制として。
なるほど、運用ができないっていうことですね。
管理の運用ができないってことなんですね。
そうですね、その辺も後で少し話すと思うんですけど、
本部流の開発体制的に全てのビルド済みバイナリーを用意するっていうのは、
多分正直開発速度的に現実的じゃないと思いますね。
なるほど、そういう背景というか各ツールの運用体制みたいな背景があるので、
基本的に本部流では歴史的経緯もありつつも、
ビルドをしていくみたいなのが主であるっていうようなところなんですね。
そうですね。
違いについては結構よく分かったんですけど、
ここからはビルドをどうやっていくのかみたいな話をしていくんですかね。
M1 MacとLibreSSLのビルド障害
そうですね、本部流とはずれるんですけど、
自分の実体験の紹介として、昔実際あったやつ話すんですけど、
今も自分M1マック、ちょっと古いやつ使ってるんですけど、
M1マックってマックで一番最初にARMのCPU搭載したやつだったと思うんですよね、PCで。
もちろんiPhoneは前からあったんだけど、PCとしてM1マックが最初で、
だから結構当時M1マック出た当時、結構いろんなソフトウェアが動かなかったんですよ。
そうですね、アーキテクチャがサポートしてなかったってことですよね。
そうですね、なので結構いろんなソフトウェアが頑張って対応したんだけど、
実は何回かこのPodcastで紹介してるLibreSSLがコンパイルが、
LibreSSL単体だと確かコンパイルできたんだけど、
Nginxと一緒にビルドすると動かないって問題があったんですよね。
なるほど、M1マック上でビルドするとき。
そうですね、最初そのうち直るかなと思って放置したんだけど、何年経っても直んなくて、
これは自分がやんなきゃダメかと思って調べたことがあって、
でもLibreSSLって前も言ったと思うんですけど、
マック上のOpenSSLってLibreSSLだから、LibreSSLは絶対コンパイルできるはずなんですよ。
使えるはずではありますよね。
ソースコード的には絶対に動くはず。
なのになぜかコンパイルができないっていうので、一個一個調べていったら、
LibreSSL側に入ってるconfig.guessとかconfig.subっていうこのファイルがあって、
そのファイルはCPUとかOSとかの実行環境を判定したりとか、
あとその環境名を正規化したりとか検証したりするような仕組みだったんですけど、
このファイルが古くてApple SiliconのM1マックに対応してなかったんですよ。
なので判定させると不明なプラットフォームみたいな判定になっちゃって、
コンパイルができてなかった。
なのでこれ結局どうしたかっていうと、
config.guessとかconfig.subはLibreSSLとは別のプロジェクトで元々管理されていて、
それをコピペしただけだったんですよ。
なのでその大元の方を見に行ったら、大元の方はもうApple Siliconに対応してたので、
それを自分がコピペしてきて、これで更新してくださいって言ったらマージしてもらったっていうところで。
それでLibreSSLはNginxと一緒にM1マック上で使えるようになった。
M1マック対応がなされたんですね。
そう、自分のプリリックでなされたっていうところで。
ちょっと気になるのが、M1マック上でOpenSSLのコマンドはもちろん入ってると思うんですけど、
買ってきた状態で、一番最初の状態で。
そのOpenSSLのコマンドはLibreSSLじゃないですか。
なのでAppleの社内でApple Silicon製のMac OSをビルドするときには、もちろんLibreSSLをビルドしてるわけですよね。
そうですね。
構築してるわけですよね。
で、その中ではこのconfig.getとかconfig.subの中身のOSの判定だったりCPUの判定だったりっていうところはもちろん直ってたっていう話ですよね、きっと。
これが正直わかんなくて、自分も疑問なんですよ。
AppleがLibreSSLどうやってコンパイルしたりとか管理してるのかがちょっとよくわかんなくて、自分も。
ですよね。この事例見てしまうと。
そうなんで、ちゃんとAppleはLibreSSLの本気に還元しているのか若干この時疑問に思ったんですけど、
LibreSSL単体は一応コンパイルできたと思うんで、もしかしたら本当に気づいてないだけかもしれない。ちょっとわかんないですね。
なるほど。本当にもしかしたらLibreSSLを若干カスタマイズしているものが標準では入っているみたいな話なのかもしれないっていうのもあり得る話ですね。
そうなのかもしれないなと思ってて、実際カールとか明らかに挙動違ったりするからMacのやつって。
それはMacに標準で入ってるものか。
そうMacの標準のカール、確かLibreSSL周りの挙動が確か明らかにデフォルトと違った記憶があるので、何かいじってそうな気配はしてるんですがちょっとよくわかんないですね。
じゃああり得る話ですね。Macに入れる際に若干カスタマイズしてインストールしてビルドしてっていうのは間違った話ではない。
可能性はあるなと思いつつちょっと詳しいことはわからないのでちょっとうかつなことは言えないんですが。
なるほどそういう事例があったっていうことですね。
そうですね。なのでこんな感じで自分でコンパイルしようとするとMac上で何かいろいろトラブルに遭うことはありますよっていう紹介ですね。
ソースコードからビルドする場合にはちょっと面倒くさいことが。
まあ起こりうるよねっていうところ。でHomebrewはそういうの1個1個実はやってくれているっていうところで。
なのでHomebrewに戻ろうかっていう感じなんですが。
ちなみにこのその時LibreSSLのビルドが失敗した時ってHomebrewでLibreSSLを入れるってことはできなかったですかね当時。
どうなんだろうLibreSSL入れたことないですねHomebrewで。
なるほど。
単純にあのHomebrew経由であのやったことはないからわからんっていう。
そうですね当時結構前の話なんでそのM1Mac出て1,2年ぐらいの話なんでちょっと覚えてないですね。
もしかしたらHomebrew経由だったら簡単にインストールできた可能性は当時あったかもしれないっていうぐらい。
まあそうですねLibreSSL単体は多分いけたんでそのNginxと一緒にコンパイルするとかその他のやつと組み合わせる時になんかエラーになったんですよね。
そうだからなんかそのコケるとしたらKarlの方なんじゃないかな。
当時コンパイルしたことはなかったんですけどMacのKarlでKarlとLibreSSLが一緒になってるはずなんでその辺どうやってコンパイルしたのか正直ちょっと疑問には思いましたね当時。
Appleが。
まあまあちょっとわかんないです。
HomebrewのFormulaとPortable Ruby
じゃあHomebrewの話にちょっと戻して話できればなと思うんですけど。
でHomebrewはその2009年ぐらいから登場したやつなんですけどさっきから言ってる通りそのビルドとかインストールを管理するっていうソフトウェアで今だと実はLinuxでも動作するらしいんですけど自分
は使ったことないので今回Macの話をしますと。
でHomebrew CoreっていうそのHomebrewのデフォルトでインストールできるやつは実は今回調べたんですけど8000以上あるんですよね。
あのHomebrewが対応しているソフトウェア。
ブリューインストールなんとかでインストールできると思うんですけどそのインストールできるソフトウェアがなんと8000以上ある。
すごい量ある。
だからこの辺がそのバイナリーで配れない理由なんだけどその8000以上あるから管理できないっていうのが一番大きい理由ですね。
でも一応その今だとなんかボトルって言われているそのビルド済みのパッケージを配布する方法もあるんですけどこれは本当に一部の有名なやつだけが対応されているって状況でほとんどは普通に自分でビルドするって形
ですね。
ビルドスクリプトが配布されている形式になってるっていうこと。
そうですね。でそのビルド方法とかはRubyのスクリプトで書かれていますと。
うん。
でこの辺は自分であのHomebrewの設定書くこともできて、で自分のレポとかに置いてブリュータップってやつやるとそれをなんかインストールというかその読み込んで独自のHomebrewのスクリプトでブリ
ューインストールとかできるようになる。
うんうん。
なのでそういう使い方もできますと。
だからあの自分の極端極端な話というかあのやってる人もしかしたら結構いるかもしれないですけど環境構築自分のMacの環境構築をそのHomebrewタップしてでHomebrewインストールとかですかね。
うん。
するだけであのできるようにするっていう設定もまあできなくはないっていう。
全然やってる人いて自分のOSSをそのブリュータップしたらインストールできるよみたいな感じでリードミーに書いてる人もいるし。
うん。
全然そういうことやってる人は全然いる感じですね。
うん。
であのこの辺はまあRubyであのやっていてまあなんかHomebrewが登場した当時ってMacにRubyが標準搭載されていたし当時結構Ruby流行ってたので。
うん。
あと当時RubyであのDSLを定義してなんかその設定ファイルっぽいんだけどプログラムを書けるみたいなそういうの結構流行ったんですよね当時。
流行ってましたね2009年2010年あたりちょっと思い返してみると大体のことがなんかこうRubyで書いていたなぐらいなことがちょっと思い出されますね当時は。
そうですねまあなんか結構それ捨たれちゃったかなと思いつつまあHomebrewはねまだ全然使ってます。
なのでまあRubyを触ったことある人だったら別にあの見慣れた感じかなと思いますね。
DSLの設定技術ですよね。
そうですね。
やり方としては。
だからソースコードでそのDepends onってやつもあってこれはこのライブラリに依存してますよみたいなのも書けるんですよ。
そうしとくとそれがインストールされてなかったらインストールしてくれたりとかそういうこともできる。
依存関係の解決までしてくれるってことですね。
そうですね。
なので結構ねあのいろいろ設定かけて便利っていうのがHomebrewですね。
はい。
まああのMacに標準でRubyが入ってるからこそ別にRuby自体を入れる必要性もないしっていうことですね一番最初のセットアップの時。
そうですね。今だとRubyが入ってないケースもあるのでまたポータブルRubyってやつを使ってるらしいんですけどもともとはMacの標準のRubyを使っていたはずですね。
そうなんですね。Homebrewの中で使ってるRubyってポータブルRubyなんですね。
のはず今は。
今は確か新しい。
標準のRuby。
そうですね。新しいMacそもそもRuby入ってないじゃなかったかな。
なるほど。そういう理由があるからポータブルRubyでHomebrewの中にRubyを入れてしまってっていうことですね。
そうですね。Homebrewをインストールする時にRubyもポータブルRuby入れちゃってっていうところのはずですね。
なるほど。あれですもんね。そもそもHomebrewを動かすためにXコードをインストールしないといけないだったりとか。もろもろのセットアップはありますもんね。
そうですね。それがないとそもそもビルドできないからHomebrew入ったところでっていうところはあるんですけど。
なるほど。内部としてはじゃあポータブルRuby使ってRubyのスクリプトを動かしてるって感じ。
そうですね。今はそんな感じのはずですね。
SIP・プレフィックス・リンク管理
MacのLinuxと違うところって結構いろいろあってディレクトリ構成がMacとLinuxって結構違うんですよね。
ApptとかだとOSで管理してるのでApptインストールとかした場合はユーザービンとかユーザーリブとかにいろいろ入ってくると思うんですよね。
Linuxだと自分で手でコンパイルしたやつはユーザーローカルビンとかそういうところにバイナリー置くことが多いと思うんですよ。
けどその辺のルールがMacって全然違う。
しかも今のMacはシステムインテグリティプロテクションっていうSIPって呼ばれてるやつがあってなんとrootでも変更できないファイルがあるんですよ。
これはセキュリティ的な理由でこういったシステムが入ってるってことですね。
そうですね。もうAppleが管理してるからMacのユーザーも変更できない。
ルートだったとしても。
そうルートでも変更できない。
すらシステムとかすらユーザービンとかこの辺はルートでも今変更できないようになってますMacの場合。
MacOS側がもうシステム上弾いてしまうってことですね。
もう絶対できない。Appleが管理してるからもう誰も触れない。
そう聞くとすごいOSだなと思ってしまいますけど。
そうですね。ユーザーにいじらせないファイルがあるってどういうことってちょっとLinux普段使ってる人間からすると思うけどMacはそうなんですよ。
不自由すぎないっていう気がしますが。
こういうの見るとMacって不自由なOSなんだなっていうのを認識しちゃうんですが、その辺がホームブリを使ってると正直あんまり気にしなくて良い感じにはなるので、その辺もやっぱホームブリを使う意味かなと思
ってます。
だからホームブリを使えばLinuxみたいな感じでいい感じに権限も問題なくさまざまなソフトウェアをインストールできるってことですよね。
そうですね。Macの特殊事情を知らなくても基本的なLinuxとかUNIXの基本的なビルドの方法とか知ってればMacブリインストールで何となく何やってるかわかるって感じになる。
すごい便利ですよね。そう聞くと。
MacOSが不自由だけどそこら辺を感じ取らせないようにしてくれているっていうのは。
だから自分ホームブリを好きでやっぱそのMacの特殊事情とか正直あんまり知っててもあんまり使えないじゃないですか。
だって普段だって仕事だと基本Linuxでソフトウェアを動かしてるからMacの特殊事情を知ったところで雑学にしかならなくてあんまり知りたくないっていうか知りたくないわけじゃないんだけど知ってもあんまり意
味ないなと思ってるんですよ個人的に。
そこ頑張る必要性薄いよね。
あんまり頑張りたくなくてそれをホームブリは全部隠蔽してくれてるのがすごく自分が気に入ってるところですね。
めちゃくちゃいいですね。
あとあれですねMacOSのそういったセキュリティ的な事情に追従していってくれてるっていうのもいいですよね。別にこっち側が頑張って調べなくても。
結構ね困る人がどんどんプレリクエストとか送ってどんどんマージされていってるんでホームブリって。だからそういうなんかバグとかあったらすぐ治るんですよ。
そういうのがどんどん治っていくっていうのがすごい嬉しい。自力でやろうとすると本当に一個一個調べないといけなくてすっごいめんどくさいはずです。
あと分かりづらいと思いますね。Macの事情とかを紐解いていくっていうのが。
そうですね結局Linux詳しかったらできるって感じじゃないこともあるので。
絶対違いますね。
なんで正直そういうのにはまりたくないんだったらホームブリを使うのがおすすめです。
とりあえず使っておけば何も考えなくていいから楽であるっていう。
ちょっとここらへんに関してはあれですね。ホームブリというかMacOS側のシステムのセキュリティの事情が結構ガラッと変わったのが多分5年前とか段階があったかなとは思うんですけど。
でその時その段階のそのMacOSがアップデートされてセキュリティが強化されてしまったみたいなタイミングだとやっぱりホームブリ側もまだ通常できてないみたいなタイミングがあって若干使いづらいみたいないう
時期はあったんですけど最近だったらもう通常完全にされてて特に不自由ないっていう感じですよねセキュリティ周りに関しては。
なんかその今だとユーザーローカルっていうディレクトリーがあのさっき言ったそのアップルの管理から除外されてるんですけど確かなんかねこの辺混乱があったんですよね。
その時にホームブリが使えなくなんか動かなくないみたいなので結構トラブった認識なんですけどあの今その辺は解決済みですね。
あとそのインテルマックだとあの今もマックあのホームブリの標準プレフィックスってユーザーローカルなんですけど今もインテルマック使ってほぼいないと思うんであのアップルシリコンだとオプトホーム流
っていうディレクトリーになってるんですよ。
そう変わってますよねあのM1マックから。
そう変わっててこの辺があのこの辺もなんかねあのいろいろ事情があるらしいんですけどなんかそのアップルのやつとあとロゼッタ2でインテルマンのやつまあ今もロゼッタ2ないかなと思うんだけどそこを共存させるため
にこういうわけでたりとか昔したみたいですね。
ちょっと面倒。
そうめんどくさいんだけど。
めんどくさい事情があってちょっとディレクトリーごとにちょっと違ってるので本当にこの移行のかときちょっとめんどくさかったなというのは正直ありますね。
まあそうですねこれなんか急に来たからねアップルが急にもうユーザーローカル触らせませんみたいな感じで来たからまあまああれはちょっとしょうがなかったかなと思いますね。
でも本当に今だったらもう全く問題ないので。
そうですねまあなんかまあ今後も多分あるとは思うんですけどアップルが突然こういうことにやりますって言って混乱するっていうのはでもそれはホームブリューに限った話じゃないんで仕方ないかなと思います。
それはもうMac使ってる上でしょうがないところですもんね。
そうですね。
っていうまあちょっとMacがこうめんどくさいところもいい感じに隠蔽してくれるのがめちゃくちゃいいホームブリューっていうところなんですけど。
そうですねホームブリューあとなんかその複数のバージョンがあった時にちゃんとそのディレクトリーを分けてでシンボリックリンクで貼ったりとかしてなんかうまいこと管理できるような仕組みがあったりとかするんです
よ。
そんな感じになってるんですねちゃんと。
そうなんか結構中見ていくと結構ディレクトリー深くなってて結構なんか結構難しいというか複雑なディレクトリー構成になったりするんですけどその辺もねなんかいい感じに管理してくれますね。
なるほどじゃあさっきのディペンズオンじゃないんですけど例えばAっていうコマンドがBっていうコマンドのこのバージョンに依存しているっていう時にそのBっていうコマンドは他のコマンドとかにも依存されていて複
数バージョン動くことがあるみたいなイメージなんですかね。
まあちょっとそれはなんか複雑だけどなんか複数のバージョン競合しやすいやつとかあると思うんでそういうのはなんかトラブルこともあると思うんだけど意外と使えたりとかしますね。
すごい。
ブリュー結構その辺ちゃんと考えられてますね。
そのバージョン違いみたいなところもちゃんとサポートされているんですね。
そうですね。でなんか結構そのディレクタリー深くしてシンボリックリンク貼るっていう前提になっていたりするのでだからブリューリンクっていうコマンドがあったりとかしてそのブリューリンクでそのリンクしたり
とかするとなんかデフォルトのバージョン変えられたりとかなんかそういう色々できたりしますね。
その辺なんかちょっと面倒くさいこともあるんですけどなんか色々できて便利って感じですね。
ちょっと自由度高くっていう感じですね。
そうですね。
ただ基本はリンクとかアンリンクとかは使わなくてもいいっていう話なのかなとは。
でもねなんかねコマンドによってはブリューリンク打たないと使えませんとかもあったりするのでそれは出るんですよ。
この後インストールした後にブリューリンクしてくださいとかって出るのでその時に打ったりとかしますね。
案内でインストール後の案内で出てくるってことですね。
そうですね。
っていうのはあると。
はい。
Formulaの作成とtapの信頼性
でなんかじゃあここで具体的にじゃあフォーミュラーって言うんですけどそのRubyのコードでどんなことを書くとそのビルドスクリプトみたいなやつ書けるのかっていうところで。
そのクラスを定義してその中になんかいろいろ書けるんですけどソースコードのURLを書いた後にシャーニゴロっていうのを設定しないといけなくてこのソースコードをダウンロードした後にそのシャーニゴロが一致する
かどうかとかチェックしてくれると。
ダウンロードしてきたソースコードが検証ちゃんとされているものかどうかというか正しいものかどうかっていう。
正しいものかちゃんと検証してくれる。でその後にDepends onとかさっき言ったやつも書ける、依存も書けるしその後にインストールって例えば関数定義してあげるとその中になんかそのスクリプトシャーニゴロ
みたいなのが書けるようになったりとかする。
コマンドが単純に書けるって感じですね。
普通はシステム使うんだけどこれは普通にRubyの仕組みですね。なのでこの辺のやつ書いたりとかあとテストもかけたりとかしてこれインストールした後にこれ実行してちゃんと動くかテストするとかそういうのも設
定できたりとかするしこの辺のビルドスクリプトに必要な仕組みが基本RubyのDSLで全部用意されているっていう感じですね。
テストに関してはきっとあれですね。テスト実行した時にExit0が返されるかどうかみたいな感じで見てるみたいなイメージでいいのかな。
そうですね。そのイメージでいいと思います。
こういった形でフォーミュラのRubyのスクリプトを書けばローカルでちゃんとインストールがそのソフトウェアとしてできるっていう形になってると。そういう仕組みになってると。
自分でフォーミュラを書きたい場合は手元でRubyのファイルを直接実行するってこともできるんですけどただ気をつけて欲しいのはホームビルデベロッパーイコール1っていう環境変数を渡さないと直接ファイルは実
行できなかったりとかするのでそういう設定とかは一応ありますね。
なるほど。ホームビル基本はしないよねってことですよね。
自作しなければしないですね。
本当にお前はホームブリューの開発者だからそれをやるんだよなっていう環境変数を設定しないといけないってことですね。
そうですね。これはいいと思ってて手元のファイルで急にインストールとか始まったらそれウイルスかもしれないし基本的にはそういう特殊な設定しないと使えないようになってるのは安心かなと思ってますね。
ただ逆に自分で作りたい場合はその辺も知らないといけないってことですね。
まあまあまあそれは開発者だしなという。
そうですね。
基本はブリューインストールなんかパッケージ名みたいな形で入れるっていうことですね。
そうですね。まずブリューインフォでやってもらうとそのパッケージで渡せるオプションとかいろいろ出てきたりするのでそれを見つつブリューインストールすればいいしブリューインストールでいろいろオプション渡せる
からそのオプション渡してちょっと設定変えるとかもものによってはできる。
なので個人的にはそのブリューインフォインストールする前にブリューインフォしてなんか自分に合ったオプションないか探すのをお勧めしてますね。
そのインフォで見てくる先って何なんですかね。
普通にファイルですよ。
フォーミュラーのRubyのファイルに基本的にその辺の設定書いてある。
なるほど。そのインフォでこれを表示してねみたいないうのが書かれるっていう。
だったかななんか自動生成だったような気もするけどちょっと覚えてないですね。
でそのフォーミュラーを取ってくるというかここから取ってきてねみたいないう登録をするのがタップなんですかね。
それで言うとデフォルトは最初にインストールした段階でGitクローンされてるんですよ。
今だとブリューインストールする時に一定時間Gitフェッチしてなかったら自動でGitフェッチして更新しますね。
ローカルに入っていないフォーミュラーのRubyのスクリプトを全部のスクリプトをダウンロードし直すみたいなことがされてるってことですね。
サブンだけですけどね普通にGitクローンしてる。普通にGitでやってるだけなんでサブンがダウンロードされてくると。
なるほどあそこをGitプルしてるだけなんですね。
そうGitプルしてるだけ。
あれですよね久しぶりにブリューインストールなんちゃらとかアップデートとかすると他のやつもアップデートしてるよみたいなログが出てくるやつですよね今言ったのは。
ソースコードダウンしてるだけなんですよねそれは。
ブリューアップグレードでパッケージ名書くといろいろインストールし直したりとかするんですけど。
基本ブリューアップデートだったら基本Gitプルし直してるだけ。
今はブリューインストールするときに一定時間アップデートしなかったら自動でアップデートされるようになってるので、
基本ブリューアップデートは今はしなくていいかなって感じですね。
昔はしないといけなかったんだけど。
今言ったのはそのRubyスクリプトがホームブリュー本家に入ってる場合。
そうですね。
ちゃんと登録されてる場合はそういった形でGitプルされて、自動でGitプルされてくるけどっていう。
タップしないといけない条件っていうのは。
ホームブリュー公式じゃなくて誰か他の人が作ったホームブリューの設定ファイルを読み込みたい場合はブリュータップしないといけない。
ブリュータップでここに対してホームレアのRubyスクリプトがあるからそこから取ってきてねみたいないうことをするのがタップ。
そうですね。
っていう行為ですね。
基本的にタップをする先っていうのは信頼がおけるところじゃないといけない。
そうです。信頼できるところじゃないと何でもできちゃうんで。
信頼できるところじゃないとダメだし。
基本的にはGitHubのレポしかタップできなくて。
なのでそのGitHubのその信用できるユーザー名のやつだけブリュータップしてねっていう感じですね。
じゃあちょっと気軽にブリュータップしちゃダメですね。
ダメですダメです。
なんか変な。
普通にスクリプトかけちゃうから何でもできちゃうんですよ。
普通にユーザ権限で実行できちゃう。
普通にできちゃいます。
危ないですね。危ない。
あんまじゃあやるべきではないというかちゃんと理解してやるべき行為なのかなっていう。
そうですね。
ここに関しては。
で自分は実は独自のフォーミュラを作っていますと。
それは前も紹介したかなと思うんですけど。
カールを自分で欲しいカールビルドしてるんですけど。
そのビルドが結構めんどくさい。
いろいろなソフトウェアダウンロードしてみたいな感じなんで。
すごいめんどくさいんで。
以前は手でやってたんですけどこれめんどくさいなと思ってフォーミュラにしたので。
今は自分のやつブリュータップすれば一応インストールできるようになっているっていう感じですね。
ビルドスクリプトをフォーミュラでまとめてるって感じですね。
そうですね。
シェルスクリプトでもいいんですけど。
Macだったらブリューインストールできた方がいいかなっていうのでブリューインストールしてます。
それで結構便利っていうような。
便利ですね。
ブリューで全部まとめて扱ってくれるんで。
自分でビルドしちゃうとその辺のファイル全部自分で管理しないといけなくなっちゃうんで結構めんどくさいですね。
そこで生きてくるのがさっき言ってたMacOSのセキュリティをいい感じにしてくれるっていう仕組みがそこで働いてるって感じですかね。
シェルスクリプトで準備するとそこら辺までケアしないといけないっていうのが入ってくるけどホームブリューであればいい感じにしてくれる。
そうですね。正直カールに関してはそこまで生かしてはない。
別にコンフィギュア、ソースコードダウンロードしてコンフィギュアとかすれば基本動くのでカールに関してはね。
なのでそこまでじゃないんですけどソフトウェアによってはこのライブラリーを読み込ませないといけないとかいろいろあるのでそれが楽になったりしますね。
なるほど依存先のツールを取ってくるときにめんどくさいよねっていうところなんですね。
取ってくるアップルの公式で入ってるやつとかでもいろいろLinuxと違ったりするのでそういうの渡すってなるとめんどくさいですね。
逆にそのフォーミュラを自分で管理して運用してるわけじゃないですか。
新しいMac使う場合はタップしてインストールしてってことをやってるわけじゃないですかカールに関して。
逆にめんどくさいことないですか。ホームブリューで。
ホームブリュー書くのはちょっとめんどくさいですよ。
フォーミュラを設定を書くのが。
ちょっとめんどくさいし、あと失敗したときに開発中でうまく動かなかったときとかに調査するのは若干めんどくさい。
それはホームブリュー独自のことだからってことですかね。
そうですね、あんまり自分がホームブリュー慣れてないっていうのもあるし、
あとどこで途中でコケたときにそこから再開っていうのは基本できないんじゃないかな多分。
もう一回一からやらないといけない。
途中でもう依存先のパッケージとか全部取ってきてるんだけどなんか微妙にインストールコケたみたいな、ビルドコケたみたいないうときに中途半端な状態になってしまう。
そうですね、そういう場合はもう最初から言い直すしかない。
そうですよね、巻き戻しみたいなことは基本的にはできない。
そうですね、ただシェルスクリプトだったらなんかその途中から手で再開すればいいってなるんだけど、
ホームブリューだと基本できないんじゃないかな。
ちょっと分かりづらいってことですよね。
そうですね、自分が知らないだけかもしれないけど。
そういうなんか設定ってか一番最初のあれこれはちょっとめんどくさい、独自だしめんどくさいところはあるけど、一回整っちゃえば基本はできる。
一回整えばそのホームブリューで色々ファイル管理してくれるんで便利ですね。
どこにファイルがあるかとか分かんないんで、そこは若干めんどくさいんですけどってことですね。
どこにファイルがあるかっていうのをそのビルドした成果物。
ビルドしたファイルとかがホームブリューの管理になっちゃうので、ホームブリューが便利なところに置かれてるので、自分が見に行きたいときどこあるかっていうのは調べないと分かんないですね。
実体がどこにあるかってことですね。バイナリとか成果物の。それはホームブリュー管理家になるからってことですね。
そうですね。自分で書いてなかったらあんま気にならないと思うんですけど、自分で書いたフォーミュラだとちょっと見たいってケースたまにあったりするんで、そういう時にこれどこにあるんだろうってはなりますね。
それもさっき言ったmacOSのセキュリティ運営とかでいろいろディレクトリ変わってきてるわけじゃないですか。ホームブリューの管理のディレクトリも。やっぱそこら辺が影響してそうですよね。あれ今までここに
あったんだけどなみたいないうのがホームブリューの都合でちょっと変わっちゃうみたいな。
決めの問題なんで、そこはいいんですけど、シンプルに結構深いところにあるので、ディレクトリ深いとこあるから調べないとどこにあるか本当わかんないですね。
なるほどね。ディレクトリの構成自体が深すぎてってことですね。
そうですね。そこはちょっとめんどくさいめんどくさいっていうところですかね。
でもちょっと特殊事情っていうのも若干ありますね。自分でやってるから。
1回できちゃえば普通に便利ですよ。
BottlesとkekkaiのHomebrew Core登録
構築しちゃえば便利と。っていう話がちょっと自分でフォーミュラを運用していくみたいな話だったんですけど、じゃあ次はホームブリューのビルド済みのボトルの機能ですかね。
そうですね。有名なやつだったら実はボトルって言ってコンパイル済みのバイナリーをダウンロードするってことは一応できるんですよ。
けどこれは自分がよくやるんですけど、ギターブリリースで、自分GOのやつばっかり管理してるから、ギターブリリースでGOでビルド済みのバイナリー配布してるっていうレポが結構あると思うんですけど、
そういうGOのコンパイル済みのバイナリーをダウンロードしておくみたいなのはできないんですよ。
できないですね。
ホームブリュー的にはできるんですよ。ホームブリューの使用上はできるんだけど、ホームブリューコアには入れてくれなくて、ホームブリュー側でビルドしたやつしか配れない。
なるほど。ちょっと管理方法がホームブリューの方に寄ってしまうみたいなイメージですかね。
自分ってホームブリューがビルドしたやつ以外は一切信用しないっていうスタンスなんですよね。
そういうポリシーってことなんですね。
じゃあこのボトルで配りたい場合はホームブリュー側に対してちょっと設定をしないといけないみたいな。
そうですね。ホームブリューのソースコードでいろいろやったりとか、あとビルドする仕組み入れたりとか、なんかいろいろめんどくさいことがあるはず。
なるほど。なんかそれだけ聞くとあんまりやる意味なさそうだなっていう気がしてきちゃいますけどね。
正直あんまりやってるやつそんな多くはないし、あと自分とかGoばっか使うけど、Goに関してはやってくれない。
Goは基本的にGoをホームブリューでインストールして自分でコンパイルしてっていうスクリプトですね、基本的には。
基本的にあれですよね、Goの場合はGoゲットとかでゲットできますもんね、バイナリとかも。
そうですね、Goインストールとかでインストールできるので、そういうふうにやってるケースが多いのかな、ものによっては。
なんかホームブリュー管理という話ではなさそうな気がしますね、どっちかというか。
そうですね、なので自分はGoのやつに関してはホームブリュー使わずにGo自体を入れてるので、それでやるんですけど、
なんか人によっては普段Go使ってないみたいな人だったら全部ホームブリューでやりたいっていうケースはあるかもしれない。
けどGoの便利なところってバイナリ自体配布が簡単ってところだと思うんですけど、ホームブリューはそのメリットは享受できないっていうところですね。
そうですね、ちょっと管理方法が違うからってこと。
そうですね、それで言うとさっきWTAPでインストールできるようにしてる人たちいるって話したんだけど、
結構GoのやつWTAPでインストールできるようにしてる人たちのホームブリューはだいたい自分たちでコンパイルしたGoのバイナリをホームブリューで配置してるだけ、ダウンロードして配置するだけになってるケ
ースが多い印象がありますね。
だからフォーミュラでRubyのスクリプトの中に書くのがGoのビルド済みのバイナリをダウンロードしてきて、そのホームブリューの配置のところにインストールされるだけにしてるってことですよね。
の方が多分多いと思いますね。
ボトル使ってないってことですよね。
ボトル使わずにGitHub Releaseとかでやるケースが多くて、それはホームブリューのコアには入れてくんないコードになる。
別にブリュータップしてるから、自由じゃないですか。書くコードは。
自由ですね。
だからそういうことやってるけど、ホームブリューコアには入れてくれない感じになりますね。
公式の方ではサポートされない方法ってことですね。
そうですね。で実はですね、自分の作ってるOSSいくつかあるんですけど、このホットキャストも以前紹介したかなと思うんですけど、結界っていうソフトウェアを自分作ってるんですけど、なんとなぜかホームブリュ
ーってブリューインストール結界ってあると入るんですよ。
それはボトルで配布されてるってこと?
いやボトルじゃなくて、Goをダウンロードしてきてブリューでダウンロードしてきた後に、インストールのところでGoをビルドしてるって感じですね。
なるほど手元でローカルで結界のソースコードをビルドしてインストール。
ソースコードをダウンロードしてGoビルドするっていうのをフォーミュラーで書いてあって、それをやってくれる。ブリューインストール結界すると。
すごい便利じゃないですか。
自分使ったことないんですけど。
って言ってるっていうことはこれ別に結界のホームブリュー対応を片栗さんはしたわけではない。
自分はね一切しなくて、なんかね気づいたんですよ。あれなんかホームブリュー入ってるっていうのにある日気づくっていう。
ちなみになんで気づいたんですか。
なんかねツイッターで検索したのかな。したらなんかよくわかんないのあってなんだこれって見に行ったらなんかホームブリューでなんかアップデートされましたみたいなやつで来てたって感じですね。
ちょっと作者も知らなかったな。
自分も知らない感じなんですけど。
でもブリューインストール結界で入れられるっていうことはちゃんとホームブリューコアの方で対応されて。
ホームブリューコアで入ってるけど結界はその自分がGoのバイナリーをGitHubリリースで配ってるんですよ。
だからそのGitHubリリースでダウンロードしたの配置するだけでいいんだけど、わざわざブリューインストール結界ってやるとコンパイルする自分で。
なんでですかね。なんでなんですか。
自分でビルドしたいんですよ。ホームブリューは。
それはわかるんですけど、使いたい人なんでそうしてるんですかね。
これ入れた人マジで何したかったのかわかんなくて。
結界ってもともとLinuxで動かす前提で作ったので、Macで使うことあるのかな。
自分はMacで開発してるからMacで使うことあるんだけど、開発してる人以外使うことあるのか正直謎なんですけど、なぜかねありますね。
だからやってることとしたらもしかしたらMacOSをサーバーとして使ってるってことですよね。
かもしれない。Macで動かしているサーバーのファイルを守りたい人がいるのかもしれない。
しかも環境コード付きにホームブリュー使ってるから、結界もブリューインストールで入れたかった。
可能性はある。
そうですね。これ入れた人がね、日本人ですらなくて、自分マジで全く知らない人が入れてたんで、わかんないんですよね。何に使ってるか。
でも確実にその人は結界使ってます。
その人は結界使ってるんだと思う。さすがに。
何らかの用途で結界を使っていて、ホームブリューで入れたかったから、わざわざホームブリューコアの方にプロリクを投げたってことですね。
そしたらマージしてくれてホームブリュー側が。で、今も動いてると。
すごいですよね。実績として認められてそうな気がするんですけど。
どうなんすかね。全然わかんないです。
でもなんかあれですよね。ホームブリューコアにプロリク出して、すべてのツールが認められるわけじゃないんですよね。プロリク出して。
もちろんそうですね。
何か一定の基準があるってことなんですかね。
昔調べたら一定の基準があるらしくて、何か第三者が登録する場合と作者本人が登録する場合で何か全然違くて。
多選と次選みたいな感じですかね。
第三者の場合はギターブスター75以上、ギターブフォークスが30以上、ギターブウォッチャーズが30以上のいずれか一つを満たすのが基準らしいです。
YouTubeの収益化の基準みたいな感じ?
まぁそんな感じですけど。
そういうのがあると。
作者本人だとギターブスターが225以上とかフォークスが90以上とか結構厳しくなるんですよ。
第三者が登録する場合は75ぐらいでいいらしい。
まぁ結果はそこを満たしてたから通ったって感じ?
そうですね。結果は一応今見たら134スターだったので、一応自分で登録するのは厳しいけど、第三者のやつだったら全然通るくらいなので。
まぁそれで満たしたのじゃないか?わかんないけど。
でもブリューインストール結界で入れられるようになってるんで便利って感じですね。
便利な人いたら、正直ギターブリリース配ってるんでそこからダウンロードした方が早い気がするんですが、使いたい人いたら使ってください。
誰が使ってるかよくわかりません。
わざわざ手元でもう一回ビルドし直してってことなので、若干の計算リソースの無駄加減があるんですけど。
そうですね。自分はGoのツールに関しては本ブリューで入れてないので、自分がブリューインストール結界することはないんですけど、もし使う人いたらって感じですね。
使ってみてほしいですね。ぜひね。
8000以上のFormulaを支える運用
こういう感じで自分の結界みたいに、一回本ブリューインに入ると自分が結界のバージョンアップとかすることあるんですけど、その時に自動でバージョンアップするプリリクエストが立つんですよ。
なるほど。監視対象になってるんですね。
そう監視対象になってて、自分が結界更新すると本ブリューインのプリリクエストが立って、でマージ誰かが指定って感じで更新されていくんですよね。
じゃあバージョンが固定されてるんですね、フォーミュラの方で。
フォーミュラの方で固定されてて、かつシャーニゴロ、さっき言ったシャーニゴロで指定されてるから、ソースコードのバージョンも固定されてるし、バイナリー完全固定じゃないと本ブリュー動かなくなっちゃうんです
よ。
なるほど。
なので、自分が結界バージョンアップしたら、シャーニゴロもバージョンアップして、それを人が見て、人がマージして、それでブリューコアに入るって感じですね。
なるほど、じゃあそういうCIが自動で回っていて、監視対象のリポジトリがいっぱいあるみたいな感じになってるんですね。
さっき言った8000以上あるって言ったんだけど、それ全部見てて、CIでプリリクエストを定期的に作って、それを人間がどんどんマージしていくって感じになってる。
じゃああれですね、前回とかで話したリノベートみたいな仕組みが入ってそうですね。
リノベートみたいなのをリノベートじゃなくて、自分たちでやってるっていう感じですね。
監視してアップデートがあったら、最新のバージョンの文字列と、あとはシャーニゴロのやつでプリリクを自動で作って管理していくみたいなことが動いてるんですね。
そういうのを自分たちで作ってやっている、本ブリューは。
だから本ブリューって見てもらったら分かるんだけど、すごい更新してるんですよ。
ブリューコアもどんどんどんどん、バージョンアップとかあったら全部マージしてるし、だからブリューアップデートって打つとGitプルできるんですけど、
基本的に1日、次の日とかにあったら絶対何かしら降ってくると思いますよ。基本毎日何かしらやってると思うんで、だからそんぐらい更新が激しいんですよ、本ブリューって。
そういう運用体制だからっていうのはもちろんありつつ、すごい量の管理対象、本当に8000以上っていう感じなんだろうなっていうところなんですね。
なのでなんかまあまあすげえ開発とか大変そうだなと思うし、そんなことやってるからやっぱり自分たちさっきのボトルみたいなバイナリー用意するっていうのは結構大変なんで、8000もあったらねまあまあまあ一部
しかできないよねっていう感じではありますね。
めちゃくちゃ大変そうですよね運用。しかも本ブリューに関してはどっか企業がやってるって話ではないですもんね。
ではないですね、基本個人でやっていて、しかも基本的にデビュアンとかだと結構いろいろテストしたりするけど、本ブリューって正直1個1個はテストされてるけど複数組み合わせた時のテストとかは全然されてない
んですよ。
複数ツールを組み合わせたテスト。
複数ツールインストール同時にしたらどうなるのとか、そういうのは一切テストされてない。
単体単体がテストされてる。
単体単体でインストールできるからテストされてるけど。
なのでこの辺はボランティアでやってるし、個々のツールの便利ビルドスクリプトみたいなのが配布されているって考えれば、それは保証無理だよね。本ブリュー側では保証無理だし、自分もしハマったらそれは自分で調べ
るしかないよねっていう感じですね。
君たち開発者だしねみたいな言うのもありつつって感じですね、本ブリュー使ってる人は。
ただやっぱUbuntuのアプトとかだとやっぱりアプトインストールしまくったらぶっ壊れるとか基本ないはずなんですよ。
その辺の依存関係とかちゃんと見てるから。
なのでその辺はやっぱりアプトとかとは違ってその依存関係とかも完全に全部やってくれるとは限らないし、本当ビルドしてるだけだから本ブリューは。
ビルド支援ツールだって思って使うとすごい便利だけどやっぱUbuntuのアプトと一緒だって思って使うとなんだこれってなってしまうかなと思いますね。
それで言うとアプルがmacOS向けの依存管理ツールというかパッケージマネージャーみたいなのを出して欲しくはありますね、本ブリューみたいなものを。
出して欲しいなって昔自分も思ってたけど今の本ブリュー見てるとこれアップルやらないでしょって思っちゃいますね。
なるほど。本ブリューに任せちゃうかなみたいな感じですかね。
実際まあそれで多分困ってる人あんまりいないだろうし。
まあまあまあそうですね。
なのでまあまあ出ないんじゃないかなアップルからは。
管理も大変だしね。
管理も大変だしお金も自分でビルドしようとしたらお金すごくかかっちゃうからやらないんじゃないですかね。
まあそれが若干あのアップストアとかだよねみたいないうところはありますねじゃあ公式のmacOSとしてのツールの管理は。
まあそうですねまあアップストアだとまだそのお金があの有料のシェアウェアとかあるからお金が稼いでするじゃないですか。
けどなんかその本ブリューみたいなやつってお金払う動線とか動画がいてもないんですよね。
そういうシェアウェアじゃないですからね。
だからまあやらないでしょうと思いますね。
ビジネス上ねちょっと難しいね。
ビジネス上絶対儲からないところからお金がめっちゃ出てくるのが分かってるのでまあやんないんじゃないですかね。
そこが主戦場じゃないよねmacOSみたいなところですね。
一応ユニックス対応にはしてその辺のツール多分ビルドできるから後は好きにしてみたいな感じだと思いますね。
開発者頑張れってことですね。
そうですね。
結構本ブリューに関して中のことから何でそういう仕組みになってるのかみたいないうところまで見てきたんですけど何か他思ったりしますかね。
そうですね。
なんかね、マジで何で結界が登録されたのか分かんないんですけど、
たまに見ることあってその本ブリューに自分のツールが本ブリューに登録されるの夢ですみたいなこと言ってる人たまに見ることあって、
別に自分はそんなことを考えたこともなかったんですけど、なんか気づいたら登録されてたんで、
なんかもしそういうのが夢っていう人いたらなんかもしかしたら第三者の人が登録するといいかもしれません。
ただうちのその自分の知り合いの人にお願いするとかはそれはあのチートだからダメだと思うんですけど、
第三者の人が行くとまあ割とちょっと基準緩いんでそっちを狙うといいかもねと思いますね。
狙えないですけどね。
狙いようがない。結界マジでなんで登録されたのかいまだに分かんないんで、
まあまあまあまあそういうのが、そういうこともありますよってところですかね。
なるほど。やっていけばもう少ししたらそういうミラクルも起きるかもしれない。
いるかもしれない。
あとまあやっぱ本ブリュー実際見てほしいなと思ってて、
すごい開発体制もすごい勢いでマージしてるし、
あと一個一個の設定ブリューインストールしたときに一個一個のファイルとか見に行く結構簡単に見に行けるんで、
見に行くとなんか結構単純にビルドしてるだけだなーってやつもあればなんか結構いろいろオプションがあって、
こういう時はこのコンパイルオプション増えるんだなーとかなんかそういうのも見れることあるし、
物によって本当にバラバラなんで、
本当にその本ブリューってその一つ一つのソフトウェアで、
これが便利などうすればMacで便利かっていうのを一個一個考えられて作られたりするので、
結構ぜひ見に行ってほしいなと思ってますね。
その本ブリューコア公式の方をってことですかね。
そうですね。自分がブリューインストールしたやつのスクリプトとか見に行くとまたちょっと違うものわかるんじゃないかなと思いますね。
こうやって設定してんだなーみたいなのがちょっと垣間見れる。
ただビルドしてるだけってやつももちろんあるし、もうちょっとめんどくさいことやってるやつもあるし、
物によって本当にいろいろあるんでぜひ見てみてほしいですね。
Homebrewの安全性と利用者の判断
あとあれですね、昨今やっぱセキュリティ的な怖さっていうところが結構あるなーという中で、
こういう仕組みホームブリューみたいな仕組みで、
公式ホームブリューコアに対してそういうセキュリティ的な何かしらがあり得る可能性あるじゃないですか。
ありますあります。
そこをどうしていくのかみたいなのも結構課題点だなーっていうのは思ったりしますね。
そうですね。それ結構ね、昔から言われてはいるんですよ、ホームブリュー。
結構やってることめちゃくちゃじゃないとは結構言われてはいて昔から。
ホームブリューは確かに正直セキュリティよりも便利さの方が優先されてる印象はありますね、チームが見てて。
なるほど、自由にできる仕組みを提供していて、それに対してちょっとセキュリティ的にはちょっとおざなりになってしまってる部分は若干ありそう。
若干あるし、本当にその便利なビルドスクリプトっていう感覚だし、
あと実際ビルドしなければ基本的になんかウイルスみたいなのあったとしても、実際にビルドしなければ基本的には入んないはずなんだよね。
それはそうですね。
だからそのバイナリーの中身がそもそもウイルスだったからブリューインストールしちゃうとウイルスに感染しちゃうよみたいなのは全然あり得るんだけど、
それを実際にブリューインストールしない限りは基本発動しないんだよね。
なので、だから言ってもうホームブリューのせいじゃないって割り切っているんじゃないかなという気はしてますね。
なるほど。一番怖いのは公式の方に悪意あるフォーミュラが登録された時なのかなと思いますね。
なんですけどそれは結局そのフォーミュラが悪いのかっていうと結局そのバイナリー自体が悪いから、そのバイナリーを手でコンパイルしても結局同じことになるんだよね。
だからホームブリューのせいではないってないんだよね。
だからホームブリューはあくまでパイプであってその先の本体の方がセキュリティ的にダメなだけだよねっていうことですね。
もしそっちがダメだったら別にMacに入れようとしたら全部どうやってもダメでしょって感じになるから。
確かにそれは。
そうだからそれもあって多分ホームブリューそこまでセキュリティ気にしてないんじゃないかなって。
気にしてないとは言わないけどやっぱりその担保できないよねっていうのはある。
単純に現時点においても別にホームブリューコアになかったとしても普通にブリュータップして悪意あるフォーミュラをダウンロードしてしまえば同じことはできますもんね。
できますもちろん。ブリュータップはもう自由だからね。
それと同じで何か利用者側が気をつけようよねみたいないうのも結構ありそうって感じですね。
そうですねセキュリティに関してはもうホームブリュー側は基本もうやってくれない前提で利用者側で考えるしかないと思いますね。
それで言うともしかしたらあれですかねなんか匠ガード的な感じでブリューインストールするときに1回なんかフックでセキュリティをチェックしてくれるツールみたいなのも今後出てくる可能性は若干ありそうですかね。
それ難しいんじゃないかな。ホームブリュー見てもらうと分かるんですけど本当にいろんなURLが書かれてて例えばカールとかって独自のドメインでソースコードを配布されたりとかするし本当にはソフトウェアによって
バラッバラのURL書いてあるんですよ。
だからそれを全部見れるかっていうと見れないんですよね。
なるほど。
匠ガードとかって例えばnpmだったらnpmだけをフックしているから全部できるんですけど。
ホームブリューが参照しているURLってあまりにも滝に渡るので正直現実的じゃないですね。
なるほどねフック仕様にもいろんなものがあるので見切れないっていうのが現実ありそう。
そうですね。なのでやるとするとやっぱりEDR的なシステムコールとかで見るみたいな一般的なセキュリティのシステムの話になってくるかなという気がしますね。
難しいですねここに関しては。でも本当にやれることをやろうっていうのとあとは気をつけようよねみたいないうのが一般的な話としては重要だよね。
ホームブリュー側はあくまで便利ビルドスクリプトを提供しているだけでそのバイナリーが安全かどうかはあなたたちで頑張って確認してねっていう感じだと思います。
そうですね。それが適切な、それが最適ではないかもしれないですけど適切な。
ホームブリュー側でできることはもうそれぐらいしかないっていうところですね。
もしかしたら今後セキュリティ的にちゃんとしているというかガチガチに固めたそういうパッケージ管理ツルルルみたいないう需要はあり得るかもしれないっていうところは若干ありそうだなというのは個人的には思います
ね。
Linuxだったら自分たちでビルドしてるからその辺確認とかは極力してるだろうし実際過去もXZの件もデビアンの方で開発版の方でなんかおかしいぞって言って気づいたりとかしてるので結構そういうチェックとかは
してたりするんですけど、
ホームブリューそれやってる人いるかっていうと誰もやってないのでそこはやっぱり全然開発体制も違うしそもそもツールの思想自体違うからそこは仕方ないかなと思いますね。
そういうデメリットじゃないですけど今後ちょっと気をつけないといけないところっていうのはありつつもホームブリュー便利だよなっていうところですね。
そうですねホームブリューだから安全とか全然ないのでブリューインストールするときも自分が知ってるツール以外はインストールしない方がいいと思いますね。
安全ですねなんかマジで普通に気軽にブリュータップ何々でインターネットのサイト上に何か書いてあったからこれ実行してみようみたいな言うのは危ないのでやめたほうがいい。
絶対やめたほうがいいです。
そういう仕組みじゃねえからっていう感じですね。
そうですね。
という感じですかねじゃあ今回は。
そんなところで結構ホームブリューの中身プラスこういう感じで運用しつつあとはなんかこう自分でインストールしているものに関して若干ホームブリューのコアの部分とか見てみるとちょっと学びとかもありそうだよね
っていうところを話せたので結構良かったかなと思うんですけどということでここら辺に今回はしたいなと思います。
ヤオヨロズのOSSでは毎回一つのOSSを取り上げてそれについてカタツイてへんところで技術的なところもかぼりしながら話をしていく番組になってます。
今後もですねその7通りヤオヨロズのOSS取り上げていけたらなと思ってますのでぜひお聞きのプラットフォームでフォローと高評価の方お願いします。
またですねこんなツールとか取り上げてほしいとかありましたらコメントとかで教えていただけると嬉しいのでよろしくお願いします。
番組についての感想もお待ちしております。
Xなどでつぶやく際にはハッシュタグヤオヨロズのOSSをつけてくださると見つけやすくなるのでよろしくお願いします。
それでは今回もありがとうございました。
ありがとうございました。
