Введение

Бывший стандарт для дистрибутивов Linux

Linux Standard Base (LSB) был совместным проектом нескольких дистрибутивов Linux в рамках организационной структуры Linux Foundation для стандартизации структуры программных систем, включая стандарт иерархии файловой системы. LSB был основан на спецификации POSIX, Единой спецификации UNIX (SUS) и нескольких других открытых стандартах, но расширял их в определенных областях. Согласно LSB:

Цель LSB – разработать и продвигать набор открытых стандартов, которые повысят совместимость между дистрибутивами Linux и позволят программным приложениям работать на любой совместимой системе даже в двоичном виде. Кроме того, LSB должен был координировать усилия по привлечению поставщиков программного обеспечения к портированию и разработке продуктов для операционных систем Linux. Соответствие LSB могло быть сертифицировано для продукта посредством процедуры сертификации. LSB определял стандартные библиотеки (с центром вокруг ), ряд команд и утилит, расширяющих стандарт POSIX, структуру иерархии файловой системы, уровни запуска, систему печати, включая спулеры, такие как CUPS, и инструменты, такие как Foomatic, а также несколько расширений для X Window System. Он также определял средства загрузки, такие как $local fs, $network, которые использовались для указания зависимостей служб в скриптах инициализации в стиле System V. Машинно-читаемый блок комментариев в начале скрипта предоставлял информацию, необходимую для определения момента вызова скрипта в процессе инициализации; он назывался заголовком LSB. Команда lsb_release была доступна во многих системах для получения информации о версии LSB или могла быть установлена с помощью соответствующего пакета, например, пакета redhat-lsb в дистрибутивах на основе Red Hat, таких как Fedora, или пакета lsb-release в дистрибутивах на основе Debian. Стандарт перестал обновляться в 2015 году, и современные дистрибутивы Linux не соответствуют ему и не предлагают его; однако команда lsb_release иногда все еще доступна. 7 февраля 2023 года бывший сопровождающий LSB написал: «Проект LSB фактически заброшен».

Совместимость с другими технологиями

LSB разрабатывался с учетом двоичной совместимости и обеспечивал стабильный бинарный интерфейс приложений (ABI) для независимых поставщиков программного обеспечения. Для обеспечения обратной совместимости каждая последующая версия была исключительно расширяющей. Иными словами, добавлялись только новые интерфейсы, а существующие не удалялись. LSB приняла политику прекращения поддержки интерфейсов, чтобы предоставить разработчикам приложений достаточно времени для адаптации в случае удаления интерфейса из LSB. Это позволяло разработчикам полагаться на каждый интерфейс LSB в течение определенного периода времени и планировать соответствующие изменения. Интерфейсы удалялись только после того, как они были помечены как "устаревшие" как минимум в течение трех основных версий, то есть примерно одиннадцати лет. LSB 5.0 стал первым основным релизом, нарушившим обратную совместимость с предыдущими версиями.

Прием

В то время как LSB был стандартом и не имел конкурентов, его поддерживало лишь небольшое количество дистрибутивов Linux. Например, для LSB версии 4.0 было сертифицировано всего 21 издание (выпуск) дистрибутивов, в частности Red Flag Linux Desktop 6.0, Red Hat Enterprise Linux 6.0, SUSE Linux Enterprise 11 и Ubuntu 9.04 (Jaunty Jackalope); для версии 4.1 было сертифицировано еще меньше. LSB критиковали за то, что он не учитывал мнение проектов, особенно проекта Debian, не входящих в круг его компаний-участниц.

Выбор формата пакета RPM

LSB предписал, что программные пакеты должны поставляться либо как установщик, соответствующий требованиям LSB, либо (предпочтительно) в ограниченной форме формата RPM Package Manager. Этот выбор формата пакетов исключал возможность использования других существующих форматов пакетов, несовместимых с RPM. Чтобы решить эту проблему, стандарт не определял, какой формат пакетов система должна использовать для собственных пакетов, а лишь требовал поддержки RPM для обеспечения возможности установки пакетов от сторонних поставщиков на систему, соответствующую стандарту.

Ограничения Debian

Debian включал поддержку LSB в качестве опции с ранних версий, начиная с версии 1.1 в "woody" (3.0; 19 июля 2002 года), 2.0 в "sarge" (3.1; 6 июня 2005 года), 3.1 в "etch" (4.0; 8 апреля 2007 года), 3.2 в "lenny" (5.0; 14 февраля 2009 года) и 4.1 в "wheezy" (7; 4 мая 2013 года). Для использования сторонних RPM-пакетов, соответствующих LSB, конечному пользователю требовалось использовать программу Alien от Debian для преобразования их в собственный формат пакетов, а затем установить их. Формат RPM, определённый LSB, имел ограниченный набор функций RPM, чтобы предотвратить использование возможностей RPM, которые нельзя было бы преобразовать в формат deb с помощью Alien или других программ для конвертации пакетов, и наоборот, поскольку каждый формат обладает уникальными возможностями. На практике не все бинарные пакеты Linux соответствовали LSB, поэтому, хотя большинство из них можно было конвертировать между rpm и deb, эта операция была ограничена определённым подмножеством пакетов. Благодаря использованию Alien, Debian обеспечивал совместимость с LSB по сути, но согласно описанию пакета lsb, наличие этого пакета "не подразумевает, что мы считаем Debian полностью соответствующим Linux Standard Base, и не должно рассматриваться как заявление о соответствии Debian LSB". Однако эти усилия прекратились примерно в июле 2015 года из-за недостатка интереса и ресурсов в проекте. В сентябре 2015 года проект Debian подтвердил, что поддержка стандарта иерархии файловой системы (FHS) будет продолжена, а поддержка LSB была прекращена. Ubuntu последовал примеру Debian в ноябре 2015 года.

Качество комплектов испытаний на соответствие

Кроме того, комплекты тестов на соответствие подверглись критике за наличие ошибок и неполноту — особенно в 2005 году Ульрих Дреппер раскритиковал LSB за плохо разработанные тесты, которые могут приводить к несовместимости между дистрибутивами, сертифицированными по стандарту LSB, когда одни реализуют некорректное поведение, чтобы обойти ошибочные тесты, а другие получают освобождение от необходимости их выполнять. Он также осудил отсутствие тестирования приложений, отметив, что тестирование только дистрибутивов не решает проблему приложений, зависящих от поведения, определяемого реализацией.