なぜ Gentoo が寂れているのか

最も本質的には、 Gentoo コミュニティが拒絶的だから なのだと言える。 言い換えれば deny とか refuse とかいうニュアンスである

「俺様の philosophy がゼッタイだ」という developer が居る うえに、その人数が多めだ。 だから例えば仲間割れして Sabayon や Exherbo が出て、しかも喧嘩をしているのである。 (比較すれば例えば Debian と Ubuntu はそんなに仲が悪いか?)

拒絶的な人が居る集団に contribute したいと思うのか?  例えば、 donate をするか?

ちなみに、俗には「否定的」と表現する人が今は多いのだろうけれども、 「否定」という表現では本質は伝わらない。 「拒絶」である。あるいは、「存在否定」という言い方をせねばならない。 拒絶をされたら、「お前は居てはならない」というかのごとく存在否定をされたら、人は来なくなる 。 当然だ

根本方針と矛盾してはならない。 かりに 「Gentoo とは choice である」というのを根本に定めたのであれば、その方針を共有し、その余のために根本方針と矛盾することがあってはならない

比較すれば例えば、 FSF は「ソフトウェアは解放的であらねばならない」というのが根本方針であろう。 だから、プロプライエタリの存在を否定する。 プロプライエタリに対しては拒絶的だ。 しかし、それが根本的な本質であるからだ。 その余においては拒絶的であってはならない

例えば

Portage をすら、多言語化をする気がない

Package Management System (PMS) は最も基本的なところで、使用が必須で、常用をせねばならない。

ところが、 LINGUAS="ru" しか無い状態で放置である。 「英語くらい読めて当然」というのと、「英語を常用せねばならない」というのとは、異なる 。 たとえ日本国籍保有者の多くが、中学校で英語を習わされているとしても、母語ではない。 PMS で母語を選べないのに「Genoo とは choiceである」とは、致命的な矛盾である 。 「日本語」が母語の人が一億人以上居ることは言うまでもないが、 中国語の話者はもっと多い。スペイン語やフランス語も多い(ただ、ラテン語系だから、English には親しい方だが)。

emerge の表示も多言語化がほぼ全くなされておらず、マニュアルすら一部分しか翻訳がなされていない。 例えば、 「欲しいソフトウェアがあるなら ebuild 書け」と云うのならば、 devmanual が翻訳されていなければおかしい 。 しかも、Portage の文書はあまりにも大部で、しかも翻訳してもらうことを想定した表現をしていない部分が少なくない(Gentoo Wiki ですら、慣用表現で書いている人が居る)。

ただでさえ emerge のエラー表示が意味不明かつ不親切なのに、母語で表示をされないのだから、 native English speaker でなければ、苦痛にも程が有る

比較すれば例えば、フリーソフトウェアが free (解放的)であるならば言語についても奴隷化されないことが当然だから、 GNU は多言語化にも力を入れている。例えば gettext は世界中で愛用されている。

コミュニティが拒絶的なのに、そこで翻訳で contribute するのにしても、途方もない不毛を感ずる。 ましてや、「Gentoo 試してみよう」「研究してみよう」という人にとっては、「Gentoo 怖い処」という印象に帰結するに相違ない

PMS を選べるのが当然なのに、他の PMS を揶揄する不埒者が沢山居る

Exherbo と喧嘩しているので、Paludis を小馬鹿にする者が沢山居る。 それどころか、 Pkgcore に対してさえ、「お前まだ Pkgcore なんか使ってんの?」って(面と向かって)云う developer が居る。 「Portageで当然だ」と思っている人が多いので、 PMS に選択肢が有ることを知らない初心者が多い

ましてや、 "install" を "emerge" と云うスラングは、公式には用いるべきではない。 ところが、 Gentoo Wiki や、ウェブのトップページや、広報文ですら、 "emerge" で書いている。 これは実に閉鎖的な態度だ。

emerge や pmerge は、オプションがないと「インストール」を始める

emerge (と、Portageとの互換性に配慮した pmerge)は、 明示が無いと「インストールしろ」という意味になる。実に危険なことである 。 他のディストリビューションと比べると、 yum, rpm, apt-get, dpkg, pacman、いきなりインストールする奴は居ない("yum install", "dpkg -i", "pacman -S")。

「emergeは普通ではない」と云いたいのではない。「emerge は危険だ」と云いたいのである これがPaludis だと、 "cave resolve -x" だ。慎重にすぎるかもしれないが、実に "cave" なことである。

また、 emerge では、「いきなりインストール仕様」であることが、 "install"=="emerge" というスラングの発想の一因なのだろう。

「いきなりインストール仕様」は、少なくとも初心者にとっては明らかに危険 である。 殆どの人に、「emerge を実行したらとんでもない Emerging が始まって、慌てて Ctrl+C した」という経験が有る。

即ち、少なくともデフォルトでは「いきなりインストール仕様」は無効にしておくべきだ。 デフォルトは "--pretend" か "--ask" にしておくべきなのである。

emerge のオプションが奇怪

例えば、多くのオプションには、短いのと長いのがあり、同義だ。そして、どちらが正式なのかはよくわからない。 例えば、"--pretend"=="-p","--ask"=="-a", "--onetime"="-1", "--verbose"=="-v", "--deep"=="-D", "--newuse"=="-N"。 これでは、初心者との会話に困る。 少なからぬ初心者が短い方を用いるし、少し慣れたら短い方にする人が多い。だから "emerge -uDN @world"等と云う人が多い。だが、初心者には、「uDN」と云われても何の意味か判らない人が少なくない

また、特に不可解なのは、 --verbose と --tree が別々で、 --verbose では --tree 表示がデフォルトでないことだ。 --verbose 自体が既に、人が目視する際に主に用いるオプションなのに、 --tree 表示が無ければ dependency が判りづらくて困る。(だから、Pkgcore の pmerge でもこんなことはしない。)

初心者に使わせるデフォルトの PMS なのか?  "Learn!"(所謂「勉強しろ」)と偉そうに云う態度がまともな社会人のすることか?  だから、嫌がられ、寂れるのだ

emerge のエラー表示が意味不明

極み付きは、「(その他○個のパッケージ)」的な表示である。 具体的に云ってくれたらそれらを解決するのだが、云ってくれない。

一部の人は、 Bug のところにエラーのファイルを attatch したり、 Forum のところに「コピペ」投稿をしている。 Portage が阿呆なのだから、この繰返しになる。"Can’t emerge" の投稿が絶えない。

そして、こうして苦情を投稿してくれるユーザはあくまでも一部であり、 多くの初心者は、黙って去る

動くようにするまでの障壁が厳しすぎる

例えば、カーネルコンフィグレーション がある。

量が多すぎる。それを多くの人は menuconfig か nconfig でやることになる (xorg-server が動いていないわけだから)。

Linux コミュニティの方に起因するのだが、これらコンフィグ項目それぞれの意味が判りづらい。 特定のマイナーなデバイス専用のものから、無いとまず動かないものもあれば、エキスパート専用のものもある。 それらが、殆ど同列に用意されている。

Linux コミュニティではおそらく、「カーネルをビルドするのはそれなりの手練れだ」と思っている。実際に、既に動くシステムを持っている人が新たにカーネルをビルドする例を想定しており、 gconfig や xconfig も一般的だと思っているだろう。それに、親切なマニュアルも無い。

Gentoo サイドがそこと噛み合っていない。 だから、 初心者がいきなりカーネルコンフィグの荒野に投げ出されて、動かないカーネルと苦闘をし、数えきれぬ再起動を繰返した上に、永遠に動かずに憤死 している。

こんなんじゃ 「Linux from Scratch」(LFS) と同じではないか?

無論、 genkernel という手段はあるが、少なくとも私のところでは動くカーネルができなかった。

つまり、 カーネルのバイナリパッケージも無いのか?  ビルド済カーネルから始める stage も無いのか? と云いたいのである。

率直に云って、 Gentoo のインストールは現状では、他のインストール済みディストリビューションから chroot する方法が良い(これはデフォルトの choice では無い)動くシステムの無い状況からGentooをインストールしてはならない

もっと現実を端的に言えば、 かなりの人が、他所からバイナリカーネルをコピペしたり、他所から .config をコピペ している。 そんなんなら 最初から、Gentoo で用意しろよ、そんな choice も否定するのか? 根本理念と矛盾している のである。

私は、 xorg-server を含め、 一般的なパッケージまでもバイナリで出せと云っているわけではない 。そこまですると Sabayon である。

Gentoo のポジションが解っていないから人が去る のだ。 即ち、怠惰なプロプライエタリ風の人には Sabayon があり、荒野でも生き抜ける人には Exherbo がある。その間が、 Gentoo の居場所だ。

Gentoo は、 Debian 風でもなければ、ましてや Ubuntu でもない。あってもならない。なぜならば、そもそも PMS も choice する し、デフォルトがソースからビルドだから。 ソースからビルドをしたくない人はまず、 Gentoo には来ない 。 だから、 (現状でもバイナリが用意されている)FirefoxやLibreOfficeは勿論、カーネルのバイナリパッケージがあっても自己否定にはならない。 何もないところからカーネルをつくるのには、何日も思考錯誤することになる、その何日もを、動かないコンピュータと浪費して、憤死するのがオチか? FirefoxやLibreOfficeよりも遥かに時間がかかるのだ。

Debian 7.0 (wheezy) を 8.0 (jessie) にアップグレードした

日記

Debian の 8.0 が stable になったので、アップグレードを行った

ひとつ差し支えた点が有った。 それは、 GRUB (GRUB2)が 「展開されているけれど、設定がされていません」という主旨のエラーを出して、 mkconfig不能になってしまったことである。 grub2-install は可能なのだが、 grub2-mkconfig、update-grub が不能

結局は、以前の GRUB を バックアップ後に purge し、再インストールを行い、 設定を書き戻し、おもむろに dpkg-reconfigure grub-pc を行った。 つまりは、GRUB については、やりなおしである。

おそらくは、GRUBのカスタマイズをしていたら、アップグレード後にこのようにconflictして頓挫する

また、 wheezy-backports を利用している人は多いだろうが、 backports のは Linux カーネルのエクストラバージョン(というか、パッチリヴィジョン)が 付いている。 jessie のと混在すると厄介なので、 GRUB の設定を書き換えて再起動のち、 backports のは消す


ところで、Debian は、stable, testing, unstable, さらには LTS とあり、コードナンバーとコードネームもあって連動せず、紛らわしいので困る。 そもそも、コードネームが憶えづらい。 Debian という名称が私的な由来であったり、コードネームがDisneyなのが、 デモクラティックでないので引っかかる。 そこが、Debianの気色悪い点である

Paludis と Portage の比較

Paludis は高機能で多機能で、作者の頭の良さはよく判る。 ただ、クセが有るので、同じような感性と賢さの持ち主でないと、馴染めないだろう。 とりあえず、 Paludis を掘ってみよう(笑

cave resolve world は、何をするか

# cave resolve world は、# emerge -upvtN @world と似た結果 になると思う

cave resolve は 常に dependency の詳細表示をする

常に emerge -vt の状態だ

-x (--execute) のオプションを付けなければ、常に pretend

fail-safe設計なんで、意図的にオプションを付けないとシステムの改変をしない

オプション無しだと勝手に改変する Portage の方が実は異常なのかもしれない。
例えば RedHat 系 yum は yum check-update と yum update に、Debian 系 apt-get は apt-get update と apt-get upgrade に分かれ、更にこれらはデフォルトが --ask 状態になっているように。emerge の方が奇特なんだと思う

指定対象が @world のような「セット」であるときには、 -Ks -kp がデフォルト

これは、対象「セット」内のパッケージ(ここでは、@world = 意図的にインストールしたパッケージ)については、 バージョン(リビジョンも含む)が上がったり USE フラグの設定が変えられたりしたときには再インストールをする。指定外の(dependency によりインストールされた)パッケージについては、必要が無い限りは再インストールをしない (--keep-targets (大文字の K ) が if-same で、 --keep (小文字の k ) が if-possible)

ポイントは、変えたい方の基準ではなく、 変えないための基準の設定をするという発想 であること
無論のこと、「セット」では無くパッケージを指定したら、再インストール( -Kn )がデフォルト

dependency で自動インストールをされたものも更新するには

emerge の -D (--deep)のように、 指定対象外の自動インストールされたパッケージも更新したいときには、cave resolve のオプションは、 -ks だ。つまり、指定対象外のパッケージも、バージョンが上がったり USE フラグの設定が変えられたりしたときには、再インストールをする

ebuild ファイルの USE フラグ等が変えられたときも再インストールをしたいなら

ま、 必要が無い んだけどね ( メンテナが「再インストールが必要だ」という判断をしたときにはリビジョンを上げるから )。だからたぶんやり過ぎ(悩みすぎ)だ

ただあえて云うと、 -Km と -km だ。 これは、「パッケージのメタデータが変わったときには再インストール」というオプション(if-same-metadata)だ。USEフラグだけではなく、そもそものメタデータで変更を検知する

で、これを @world にやると、更新祭り(笑)になる。順って、@world にはやらないべきである

繰返し云うが、再インストールが必要ならばリビジョンが上がるのだ。だから -Ks -ks で充分なのだ

USE フラグ変更の検知をしなくていいです(その方が早いし)

if-same-version なんで、 -Kv や -kv である。USE フラグ変えたかは大概は自覚が有るので(笑)、-Kv -kv で良いのかもしれない。変えたら、 -Ks -ks にすると良いのだろう

bdep (ビルドだけ必要なもの)も更新したい

emerge --with-bdeps=y と同じやつ。これもやる必要はないんだけどね。必要があるときにだけ更新をすればいいから

あえて云うと、 -B オプション


パッケージをアンインストール

cave uninstall

要らないのを検出させて消したい

dependency の計算結果によりアンインストールをしたいときは、 cave resolve の -P オプション

インストール済の全てから検出をさせてアンインストールというならば、 cave purge


dependency の検出時に、特定のパッケージを選ばせたい

-F オプションでパッケージ名称を、 --favour-matching ならばバージョン等も含めて、指定

反対に -A や --avoid-matching ならば、インストールをさせたくないものを指定

slot の扱い

英語を読めないと論理の理解に苦しむ箇所

指定対象に関しては -S 、 dependency に関しては -s で。 best-or-installed (x)、 installed-or-best (i)、all (a)、best (b)の4種類

例えば -Sx ならば、指定対象のパッケージで、ナンバー最大のスロットが未インストールならばそれだけが対象。最大のスロットがインストール済なら、インストール済スロット全て

同じように installed-or-best は、インストール済スロット全て、未インストールならばナンバー最大のスロット


@world からパッケージの名称だけを消したい

emerge ----deselect=y と同じやつ。 アンインストール♪ではなくて、@worldから消して、自動インストールをしたものと扱わせたいときね(※ /var/lib/portage/world が本体だが、これは PMS で自動生成をしたファイルという扱いなので、自分で改変をしないべきである)

cave update-world -r


equery d と同じやつ

cave print-dependent-ids

equery f (qlist)と同じやつ

cave print-id-contents

cave contents だと色付き

パッケージの情報を知りたい

cave show


そもそもなんで cave resolve なんや

dependencies resolution のコマンドだからだと思う

まとめ

Paludis は fail-safe である

デフォルトは安全

しかし、 引っかかることがあったら、Paludis は勝手に進めない。 処理をいちいち指定をしないといけない 。 しかも、 --ask 機能は無いので、コマンドのオプションで指示を出さねばならない

それが Portage だったら、勝手に進めたり、アーッてなる(笑

最悪はシステムが壊れるのである。 ものによっては、笑っては済まされない

Paludisの作者は明らかに、アーッてなったトラウマがあるから神経質なのだ

wjn's repos' info.

  Japenese , English