Slackwareが初心者にとって分かりにくい最大の理由の一つが、依存関係を自動解決しない点である。一般的なOSや多くのLinuxディストリビューションでは、ソフトウェアを一つインストールすれば、必要なライブラリや関連パッケージは裏側で自動的に揃えられる。利用者は結果だけを意識すればよく、内部構造を知らなくても困らない。
一方Slackwareでは、その常識が通用しない。ソフトウェアは単体で導入され、動作に必要な部品が欠けていれば、その都度エラーとして突き返される。何が足りないのかを読み取り、適切なパッケージを探して入れるのは利用者自身の役目である。「普通のOS」が面倒を見てくれる部分を、Slackwareでは自分で考え、判断しなければならない。
この違いは、初心者にとって非常に大きい。自動解決に慣れていると、失敗の原因が分からず戸惑うだけになりがちだ。しかし裏を返せば、Slackwareは依存関係の仕組みを強制的に意識させるOSとも言える。理解を目的とするなら有益だが、気軽に使いたい初心者には重すぎる設計なのである。
依存関係
依存関係とは、あるソフトウェアが正しく動作するために、他のソフトウェアやライブラリを必要とする関係性のことである。多くのアプリケーションは単体では完結しておらず、描画、音声処理、通信、暗号化などの機能を外部の部品に任せている。これらの部品が揃っていなければ、プログラムは起動できない、あるいは途中で異常終了する。
一般的なOSでは、この依存関係をOSやパッケージ管理システムが把握し、必要な部品を自動的に用意する。インストールしたのにソフトが正常に動かないとき、仕組みを知らないユーザーは「なぜ動かないのか」と戸惑う。表に見えない依存関係が満たされていないだけなのである。
依存関係はソフトウェアの再利用性と効率を高めるために不可欠な仕組みであり、便利さの裏側に存在する前提条件でもある。
Slackwareは迷ったらフルインストール？
他のLinuxディストリビューションでは、不要なソフトは入れすぎない方がよいとされる。パッケージが増えるほど依存関係が増え、挙動が複雑になり、競合や不具合の原因になる可能性があるからである。必要なものは後から追加でき、依存関係も自動で調整されるという前提がある。
Slackwareのインストールでは、初心者に対して「迷ったらフルインストールにしておけ」と言われることが多い。これは怠慢ではない。Slackwareが依存関係を自動管理しないことによるものである。必要になった依存関係を後で特定して追加するのは手動で行うため多大な手間がかかる。
最初からすべて入れておく方が安全であり、依存関係を削りまくった最小構成を試みるといきなり不具合に見舞われてしまう。この正反対の常識は、初心者や中級者を混乱させる。Slackwareでは「最初に全部入れること」が安定への近道であり、最近のOSの感覚を持ち込むと苦労する。
依存関係は変更される
依存関係の変更とは、ソフトウェアが依存しているライブラリや関連パッケージの内容や条件が変わることを指す。開発の過程で新しい機能が追加されたり、内部仕様が改められたりすると、これまで必要としていなかった部品を要求したり、逆に不要になる依存関係が生じる。また、依存先のライブラリ自体が更新され、互換性が失われる場合も少なくない。
一般的なOSでは、こうした依存関係の変更をパッケージ管理システムが追跡し、整合性が保たれるよう調整する。しかし管理が不十分な環境では、更新によって突然ソフトウェアが動かなくなる事態が発生する。ユーザーからみると原因不明の不具合に見えるが、実態は依存関係の変更に追従できていないだけである。
依存関係の変更は避けられないものであり、問題はそれを誰が吸収するかにある。OS側が引き受けるのか、利用者が直接対処するのか。その違いが、運用の安定性と負担の大きさを決定づける。
Debianだったらどうなるか
Debianで
sudo apt install plank を実行した場合、反応は明確である。
このコマンドを打つと、apt はまず plank を動かすために必要な依存関係を自動的に調査する。GTK、Cairo、vala関連ライブラリなど、利用者が名前すら知らなくても必要な部品はすべて洗い出される。その後、「追加で◯個のパッケージがインストールされる」という形で一覧を提示し、確認を求めてくる。
利用者が了承すれば、必要なパッケージは公式リポジトリから自動的にダウンロードされ、正しい順序でインストールされる。途中で不足や競合があれば、その時点で処理は止まり、壊れた状態を作らないよう配慮される。コマンド一発でPlankは即座に起動可能な状態になる。
このとき、ユーザーは依存関係の存在をほぼ意識していない。Debianでは「何をしたいか」だけを指定すれば、どう整えるかはOSが考える。この設計思想こそが、初心者にとってDebianが扱いやすい最大の理由なのである。
Slackwareでは
Slackwareで同じことをやろうとすると、状況は一変する。そもそも Plank は公式リポジトリに存在しない ため、apt install のように一行で終わる話にはならない。まず「そのソフトをどうやって入手するか」から考える。多くの場合、選択肢は「ソースコードからのビルド」である。
ビルドを行うには、SlackBuilds.org などからビルドスクリプトを探し、対応するアーカイブを用意するところから始まる。その時点で、必要な依存ライブラリがすべて揃っている保証はない。不足があれば configure や cmake の段階でエラーとして現れ、再び調査に戻される。どのライブラリが必要かを調べ、個別に入れ、またビルドを試す、という作業を繰り返す。その結果インストールできないことが判明したりする。
この過程でOSが助けてくれることはほぼない。順序の判断、依存関係の解釈、失敗時の対処はすべてユーザーの責任である。Debianでは「入れる」で済んだ作業が、Slackwareでは「調べる・考える・組み立てる」という工程に変わる。この差が、初心者にSlackwareが極端にキツく感じられる最大の理由なのである。
sbopkgを使ってもインストールできない
Slackwareでは、sbopkgのようなツールを使えばSlackBuilds.orgのソフトを簡単に導入できると思われがちだ。sbopkgで簡単にインストールできるソフトもある。例えば、Plankのようなソフトはそう単純ではない。
sbopkgとは、Slackware向けの補助的なパッケージ管理ツールであり、SlackBuilds.org（通称SBo）にあるビルドスクリプトを扱いやすくするためのものである。
sbopkg自体はビルド作業を補助するだけであり、依存関係を自動的に解決しない。Plankが要求するvalaや各種GTK関連ライブラリが不足していると、ビルド途中であっさり失敗する。
エラーメッセージは原因を直接教えてくれず、どの依存関係が欠けているのかを自分で読み解く。sbopkgを使ってもインストールできないという状況を理解し、初心者はツールの限界とSlackwareの思想を突きつけられるのである。
Plankのように他のディストリビューションでは一瞬で容易にインストールできるソフトでさえ、Slackwareでは途端に高い壁となる。依存関係の問題で導入に失敗し、結局は利用を諦めて代替手段を探すことになるのは珍しくない。実際にはKDEやXFCEに標準で備わっているパネル機能で代替しようとするが、機能や表現力の面で貧弱さは否めない。
さらに、日本語ユーザーに必須とも言えるfcitx5-mozcでさえ、SlackBuilds.orgにスクリプトは用意されているもののインストールはほぼ無理である。
Slackware 15.0とcurrentの罠
Slackware 15.0はすでに古く、最新環境を求めてcurrentを使用するユーザーも多い。だがcurrentの情報はさらに少なく、current特有の設定を要求される。15.0向けの設定とcurrentを混在させてしまい、環境を壊すのも珍しくない。些細な環境構築であっても継続的な調査と調整を強いられ過酷な道となるのである。
