Linux Standard Base

Linux Standard Base (LSB) は、複数のLinuxディストリビューションの共同プロジェクトであり、Linux Foundationを活動母体としてLinux系オペレーティングシステムの内部構造の標準化を行うものである。LSBはPOSIX仕様、Single UNIX Specification、その他いくつかのオープン標準に基づいて、特定の分野についてそれらを拡張している。 LSBの目標は次の通りである。 「LSBの目標は、Linuxディストリビューション間での互換性を向上させ、準拠システム上でのアプリケーションの動作を保証するよう標準規格を策定・振興することである。さらに、ソフトウェアベンダーがLinux向けに製品を移植したり開発する際の調整努力を助ける。」 LSB準拠製品の認証手続きが定められている。認証はThe Open GroupがLinux Foundationの協力の下に行う。なお、Linux FoundationはFree Standards GroupとOpen Source Development Labsが合併して誕生した。 LSBには以下のような点が規定されている。 POSIX標準を拡張した、標準ライブラリとコマンド / ユーティリティ群 ファイルシステムの階層構造のレイアウト ランレベルの定義 CUPSのようなスプーラーやFoomaticなどのツールを含むプリンタシステム X Window Systemのいくつかの拡張 1.0: 2001年6月 - 最初のリリース 1.1: 2002年1月 - ハードウェア固有仕様の追加 (IA-32) 1.2: 2002年6月 - ハードウェア固有仕様の追加（PowerPC 32ビット）。認証は2002年7月から開始 1.2.1: 2002年10月 - ハードウェア固有仕様の追加 (Itanium) 1.3: 2002年12月 - ハードウェア固有仕様の追加 (Itanium, Enterprise System Architecture/390, z/Architecture) 2.0: 2004年9月 - モジュール化され、LSB-Core、LSB-CXX、LSB-Graphics、LSB-I18n（リリースされず）に分割。ハードウェア固有仕様の追加（PowerPC 64ビット、AMD64）。Single UNIX Specification (SUS) バージョン3との同期が行われた。 2.0.1: LSB 2.0のISO版。全ハードウェア固有部分がマージされたもの（ただし、LSB-Grphics は汎用バージョンのみ） 2.1: 2004年 3.0: 2005年7月1日 - ライブラリAPIの更新。特にC++ ABIがgcc 3.4のものになった。中核部はISO POSIX (2003)、Technical Corrigenda 1:2005に基づくよう更新された。 3.1: 2005年10月31日 - ISO/IEC 23360として提出された。 3.2: 2008年1月28日 - ISO/IEC 23360として提出された。 4.0: 2008年11月11日 -このバージョンでは以下の機能が含まれた。 GNU Cライブラリ version 2.4 LSB 3.xとのバイナリ互換性 SDKによる容易化 グラフィックライブラリGTK+とCairoの新しいバージョンのサポート Java (オプションモジュール) LSB準拠のRPMパッケーシを容易に作成する方法 Crypto API (ネットワークセキュリティサービスライブラリ) (オプションモジュール) 4.1: 2011年2月16日 -このバージョンでは以下の変更が行われた。 Javaの削除 LSB 4.0から推奨されてきたマルチメディア (ALSA), セキュリティ (NSS) そしてデスクトップ関連 (xdg-utils) のトライアルモジュールが必須サブモジュールとして奨励されるように。 GTK+、CairoとCUPSライブラリの更新。 3つの新しいテストスイーツの追加。 5.0: 2015年6月2日 -このバージョンでは以下の変更が行われた。 以前のバージョンとの下位互換性を失う初めてのメジャーリリース（LSB3との互換性、一部の例外を除けばLSB3.1以降とほぼ完全な互換性がある）。 FHS3.0での変更を組み込む。 Qt3ライブラリの削除。 進化したモジュール戦略。LSBはLSB Core、LSB Desktop, LSB Languages, LSB Imaging, and LSB Trial Useにモジュール化された。 LSBは、バイナリ互換で安定したソフトウェアベンダから独立したABIを作るよう設計されている。後方互換性を達成するために、それぞれのそれに続くバージョンは純粋に追加的なものとなっている。言い換えると、インタフェースは加えられるのみで、除去されない。LSBは、LSBからインタフェースが除去されるときのためにアプリケーション開発者に十分な時間を与えるため、インタフェース廃止ポリシーを適用している。 これは、開発者にLSB中の全てのインタフェースに頼ることを許し、驚きなしに変更を計画し、周知する時間のためのものである。インタフェースは、3つのメジャーバージョンか、約11年、"deprecated"とマークされた後にのみ除去される。 LSB 5.0は、それ以前のバージョンとの後方互換性を壊した初めてのメジャーバージョンである。 LSBはメンバー企業以外（特にDebianプロジェクト）からの入力を受け付けないことで批判されている。 例えば、LSBではソフトウェアパッケージの配布形式として LSB 準拠のインストーラか、制限された形態[1]のRPM形式を指定している[2]。DebianはRPMより以前からdebパッケージ形式を使っており、Debianの開発者はそのパッケージ形式がRPMより優れていて、LSBに準拠するためにパッケージ形式を変えるのは現実的でないと主張している。Debianのパッケージマネージャとパッケージ形式にはRPMには無い機能があり、逆にRPMにだけ存在する機能もある。従って、Debianのパッケージ形式をRPMにするのは簡単ではない。 これに対処するため、LSBではそのOS自身のパッケージ形式については特に規定せず、単に RPM を追加サポートすることでサードパーティーが任意のLinuxシステム向けにソフトウェアを配布できるようにするとしている。Debianは既にオプションでLSBをサポートしている（LSB 1.1を "woody" で、2.0を "sarge" で、3.1を "etch" でサポート）が、問題はそれだけでは収まらない。DebianはRPMパッケージをネイティブのパッケージ形式に変換する "alien" というプログラムを用意している。しかし、LSB側は「このことでDebianがLinux Standard Baseに完全準拠していることにはならず、LSB準拠と解釈するべきでない」としている。 また、認証テストスイートもバグが多く不完全であると批判されている。GNU Cライブラリ主要開発者のUlrich DrepperはLSBのテストスイートについて、バグのあるテストに合格するようにした場合、ディストリビューション間で非互換が発生する原因にもなるとしている[3]。また彼は、ディストリビューションのテストだけではアプリケーションの互換問題は解決されないと指摘し、アプリケーションのテストをしていない点を非難している。 以上挙げた点以外ではLSBは広く受け入れられている。 ポータル FLOSS Filesystem Hierarchy Standard CUPS Linux POSIX [脚注の使い方] ^ “LSB Roadmap”. Linux Foundation (2008年). 2010年4月26日閲覧。 ^ “LSB 5.0 Release Notes”. linuxfoundation.org. July 8, 2017時点のオリジナルよりアーカイブ。3 June 2015閲覧。 “Linux Standard Base”. 2019年7月7日時点のオリジナルよりアーカイブ。2019年11月29日閲覧。 Linux Foundationのサイト Four Linux Vendors Agree On An LSB Implemenation (slashdot) 1998年8月26日のプレスリリース Do you still think the LSB has some value? - Ulrich Drepperによる批判 Yes, the LSB Has Value - Jeff LicquiaによるDrepperの批判への回答