Linux Standard Base (LSB) の概要と歴史ディストリビューション間の互換性を求めて

Linuxの世界には数多くのディストリビューションが存在しますが、かつてそれらの間でソフトウェアの互換性を確保しようとした壮大な試みがありました。それがLinux Standard Base (LSB)です。LSBは、異なるLinuxシステム間でもアプリケーションが同一の動作をすることを目的としたオープン標準の規格です。

この規格の核心は、ソフトウェアをバイナリ形式（コンパイル済みの状態）のまま、異なるディストリビューションに移植することなく動作させることにありました。これにより、開発者は各ディストリビューション向けに個別にビルドする手間を省き、ユーザーはどのLinux環境でも信頼してソフトウェアを利用できる環境を目指しました。

Key Facts

• 目的: Linuxディストリビューション間の互換性を高め、バイナリ形式でのソフトウェア実行を可能にする。
• ベース規格: POSIXおよびSingle UNIX Specification (SUS) を基盤とし、Linux固有の拡張を加えている。
• 標準化範囲: ファイルシステム階層 (FHS)、標準ライブラリ、コマンド、初期化スクリプトのヘッダーなどを規定。
• 国際規格: バージョン3.1および5.0がISO/IEC 23360として登録されている。
• 現状: 2015年以降更新が停止しており、現在は事実上「放棄されたプロジェクト」と見なされている。

LSBが定義した技術的仕様

LSBは単なるガイドラインではなく、システム構造に関する詳細な仕様を定めていました。具体的には、ld-lsb.soを中心とした標準ライブラリの提供や、POSIXを拡張するユーティリティ群の定義が含まれます。

また、OSの起動プロセスにおけるサービス依存関係を示すための「LSBヘッダー」という機械読み取り可能なコメントブロックを初期化スクリプトに導入しました。これにより、$local_fsや$networkといった識別子を用いて、どのタイミングでスクリプトを実行すべきかをシステムが判断できるようになりました。

ユーザーが自身のシステムでLSBのバージョンを確認したい場合は、lsb_release -aコマンドが利用されていました。Debian系ではlsb-releaseパッケージ、Red Hat系ではredhat-lsbパッケージを導入することでこの機能が提供されていました。

互換性の維持とABIの戦略

LSBの重要な役割の一つに、独立系ソフトウェアベンダー (ISV) のための安定したアプリケーションバイナリインタフェース (ABI)の提供がありました。これにより、OSの内部構造が変わってもアプリケーションが動作し続ける「後方互換性」が追求されました。

インターフェースの廃止に際しては、開発者が対応時間を確保できるよう「非推奨 (deprecated)」期間を設けるポリシーを採用していました。ある機能が非推奨となってから、少なくとも2つの後続リリースまでサポートを継続することで、計画的な移行を促していました。しかし、LSB 5.0ではQt 3ライブラリが削除されたため、このバージョンで初めて大きな後方互換性の断絶が発生しました。

バージョン展開と国際標準化

LSBは2001年の初版以来、ハードウェアアーキテクチャの拡大（IA-32, PowerPC, Itanium, AMD64など）に合わせて進化してきました。特にバージョン2.0では、Core, CXX, Graphics, I18nといったモジュール構造が導入されました。

また、LSBは業界標準としての権威付けのため、ISO/IEC国際規格としての登録も行われました。バージョン3.1および5.0がISO/IEC 23360として定義されており、汎用仕様から各CPUアーキテクチャ（X86-32, AMD64, PowerPC等）ごとの詳細仕様まで細かく分かれています。

LSBの主要バージョン履歴

バージョン	リリース日	主な変更点・特徴
1.0	2001年6月29日	初期リリース
2.0	2004年8月31日	モジュール化の導入、AMD64/PowerPC 64-bit対応
3.0	2005年7月1日	glibc 2.3.4採用、ISO POSIX (2003) への更新
4.0	2008年11月11日	GTK/Cairoの新版サポート、Java(オプション)追加
5.0	2015年6月2日	FHS 3.0反映、Qt 3削除による後方互換性の断絶

普及における課題と衰退の理由

理想が高かったLSBですが、現実には多くの課題に直面しました。まず、認定を受けたディストリビューションが極めて少なかったことが挙げられます。例えばバージョン4.0で認定されたのは、Red Hat Enterprise LinuxやUbuntuなどわずか21のリリースに留まっていました。

また、パッケージ形式にRPM（またはその制限付きサブセット）を推奨したため、Debianのような異なる形式を採用するプロジェクトとの相性が悪く、Alienなどの変換ツールを介する必要がありました。Debianプロジェクトは努力を続けましたが、最終的にリソース不足と関心の低下により、2015年にLSBのサポートを正式に打ち切りました。Ubuntuもそれに続きました。

さらに、コンプライアンステストスイートの品質不足も批判の対象となりました。テスト自体のバグにより、不適切な実装をすることでしかテストをパスできない状況が発生し、実質的な互換性が損なわれているという指摘もありました。

Frequently Asked Questions

LSBとは具体的に何を標準化したのですか？

主にファイルシステムの配置（FHS）、標準的なシステムライブラリ、共通して利用すべきコマンドやユーティリティ、およびシステム起動時の初期化スクリプトの形式などを標準化しました。

なぜ現在のLinuxディストリビューションではLSBが使われていないのですか？

規格の更新が2015年に停止したことに加え、認定プロセスの厳格さとテストスイートの不備、そして各ディストリビューションが独自の進化を遂げたため、実効性が失われたためです。

lsb_releaseコマンドはまだ使えるのでしょうか？

はい、多くのシステムで依然として利用可能です。規格としてのLSBは放棄されましたが、OSのバージョン情報を出力するこのツールは便利であるため、個別のパッケージとして提供され続けています。

LSBとPOSIXの違いは何ですか？

POSIXはUNIX系OS全般に適用される汎用的なインターフェース規格ですが、LSBはそれをベースにしつつ、Linux特有の機能やライブラリ、ファイル構造などを具体的に定義した「Linux専用の拡張規格」という位置づけです。

LSBが目指した「バイナリ互換性」とはどういう意味ですか？

ソースコードから再コンパイルすることなく、コンパイル済みの実行ファイル（バイナリ）をそのまま別のディストリビューションにコピーして動作させることを指します。