Каковы альтернативы FHS?

Я долгое время пользуюсь Linux более 15 лет, но одна вещь, которую я страстно ненавижу, - это обязательная структура каталогов. Мне не нравится , что /usr/binявляется свалкой для бинарных файлов или LIBS в /usr/lib, /usr/lib32, /usr/libx32, /lib, и /lib32т.д. ... Случайный материал в и /usr/shareт.д. Это немой и запутанным. Но некоторым это нравится и вкусы отличаются.

Я хочу структуру каталогов, где каждый пакет изолирован. Вообразите вместо этого, если у дракона медиаплеера была его собственная структура:

/software/dragon
/software/dragon/bin/x86/dragon
/software/dragon/doc/README
/software/dragon/doc/copyright
/software/dragon/lib/x86/libdragon.so

Или:

/software/zlib/include/zlib.h
/software/zlib/lib/1.2.8/x86/libz.so
/software/zlib/lib/1.2.8/x64/libz.so
/software/zlib/doc/examples/...
/software/zlib/man/...

Вы получаете смысл. Какие у меня варианты? Есть ли какой-нибудь дистрибутив Linux, который использует что-то вроде моей схемы? Можно ли изменить какой-то дистрибутив, чтобы он работал так, как я этого хочу (Gentoo ??) или мне нужен LFS? Есть ли какой-либо уровень техники в этой области? Как публикации о том, является ли схема осуществимой или неосуществимой?

Не ищу OS X. :) Но вдохновленный OS X - это нормально.

Edit : я понятия не имею , как PATH, LD_LIBRARY_PATHи другие переменные окружения , которые зависят от небольшого набора путей должны работать. Я думаю, что если у меня установлен редактор KDE, в котором установлена Kate,/software/kate/bin/x86/bin/kate то я вполне могу написать полный путь к бинарному файлу, чтобы запустить его. Как это должно работать для динамических библиотек и dlopenвызовов, я не знаю, но это не может быть неразрешимой инженерной проблемой.

Во-первых, предварительный отказ от конфликта интересов: я давний разработчик GoboLinux.

Во-вторых, предварительное требование экспертизы области: я - давний разработчик GoboLinux.

В настоящее время существует несколько различных структур. GoboLinux имеет один, и такие инструменты, как GNU Stow , Homebrew и т. Д., Используют нечто очень похожее (в основном для пользовательских программ). NixOS также использует нестандартную иерархию программ и философию жизни. Это также довольно распространенный эксперимент LFS.

Я собираюсь описать все это, а затем прокомментировать из опыта, как это работает на практике («осуществимость»). Короткий ответ: да, это возможно, но вы действительно должны этого хотеть .

GoboLinux

GoboLinux имеет структуру, очень похожую на то, что вы описываете. Программное обеспечение установлено в /Programs: /Programs/ZSH/5.0.8содержит все файлы, принадлежащие ZSH 5.0.8, в обычных каталогах bin/ lib/ .... Системные инструменты создают символические ссылки на эти файлы в /System/Linksиерархии, которая отображается на /usr¹. PATHПеременная содержит только единый унифицированный исполняемый каталог, и LD_LIBRARY_PATHне используется. Несколько версий программного обеспечения могут сосуществовать одновременно, но только один файл с заданным именем ( bin/zsh) будет активно связан одновременно. Вы можете получить доступ к другим по их полному пути.

Набор симлинок совместимости также существует, так /binи /usr/binкарты к единой директории исполняемых файлов, и так далее. Это облегчает жизнь программному обеспечению во время выполнения. Патч для ядра GoboHide позволяет скрывать эти символьные ссылки совместимости в списках файлов (но все же их можно просмотреть).

В отличие от другого ответа, вам не нужно изменять код ядра: GoboHide является чисто косметическим, и ядро ​​не зависит от путей пользовательского пространства в целом². У GoboLinux есть специальная система инициализации, но это также не требуется для этого.

Слоган всегда был «файловая система - менеджер пакетов», но в системе есть достаточно обычные инструменты управления пакетами. Вы можете все делать cp, rmи ln, хотя.

Если вы хотите использовать GoboLinux, добро пожаловать. Я отмечу, однако, что это небольшая команда разработчиков, и вы, вероятно, обнаружите, что какое-то программное обеспечение, которое вы хотите, не упаковано, если никто не хотел использовать его раньше. Хорошей новостью является то, что обычно довольно просто создать программу для системы (стандартный «рецепт» длиной около трех строк); Плохая новость в том, что иногда это неприятно сложно, о чем я расскажу ниже.

Публикации

Есть несколько «публикаций». Я выступил с докладом на linux.conf.au 2010 о системе в целом, которая охватывает все в целом, что доступно в видео: ogv mp4 (также на вашем локальном зеркале Linux Australia); Я также записал свои заметки в прозу. На веб-сайте GoboLinux также есть несколько старых документов, в том числе знаменитое « Я не бестолковый », в котором рассматриваются некоторые возражения и проблемы. Я думаю, что все мы немного менее фанатичны в наши дни, и я подозреваю, что будущий релиз примет за основу символические ссылки./usr

NixOS

NixOS помещает каждую установленную программу в отдельный каталог /nix/store. Эти каталоги называются примерно так: /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/есть криптографический хеш, представляющий весь набор зависимостей и конфигураций, ведущих к этой программе. Внутри этого каталога находятся все связанные файлы с более или менее нормальным местоположением локально.

Это также позволяет вам иметь несколько версий одновременно и использовать любую из них. NixOS имеет целую философию, связанную с воспроизводимой конфигурацией: по сути, она изначально встроена в систему управления конфигурацией. Он полагается на некоторые манипуляции с окружающей средой, чтобы представить пользователю правильный мир установленных программ.

LFS

Довольно просто пройтись по Linux с нуля и установить именно ту иерархию, которая вам нужна: просто создайте каталоги и настройте все для установки в нужном месте. Я делал это несколько раз при создании экспериментов GoboLinux, и это не намного сложнее, чем простая LFS. Вы должны сделать символические ссылки совместимости в этом случае; в противном случае это значительно сложнее, но осторожное использование монтажных креплений могло бы избежать этого, если бы вы действительно этого хотели.

Я чувствую, что когда-то был какой-то намек на LFS , но я не могу найти его сейчас.

По возможности

Особенность FHS в том, что это стандарт, он очень распространен и широко отражает существующее использование на момент написания. Большинство пользователей никогда не будут в системе, которая по сути не следует этому макету. Результатом этого является то, что многие программы имеют скрытые зависимости, которые никто не осознает, часто совершенно непреднамеренно.

Все эти сценарии с #!/bin/bash? Ничего хорошего, если у тебя нет Баша. Вот почему GoboLinux имеет все эти символические ссылки совместимости; это просто практично. Многие программы не могут функционировать ни во время сборки, ни во время выполнения в нестандартной компоновке, а затем для исправления требуется исправление, часто довольно навязчивое.

Ваша основная программа Autoconf, как правило, успешно устанавливается там, где вы ее говорите, и довольно просто автоматизировать процесс передачи правильного кода --prefix. Другие системы сборки не всегда так хороши, либо преднамеренно запекаясь в иерархии, либо ведущими авторами писать непереносимые конфигурации. CMake является основным преступником в последней категории. Это означает, что если вы хотите жить в этом мире, вы должны быть готовы к тому, чтобы заранее проделать огромную работу в системах сборки других людей. Это настоящая проблема - динамически исправлять сгенерированные файлы во время компиляции.

Время выполнения - другое дело снова. Многие программы предполагают, где находятся их собственные файлы или файлы кого-то другого, относительно них или абсолютно. Когда вы начинаете использовать символические ссылки для представления согласованного представления, многие программы сталкиваются с ошибками при их обработке (или иногда, возможно, правильным поведением, которое вам не помогает). Например, инструмент foobarможет ожидать найти bazисполняемый файл рядом с ним или в ../sbin. В зависимости от того, читает он символическую ссылку или нет, это могут быть два разных места, и ни одно из них не может быть правильным в любом случае.

Объединенная проблема - /usr/shareсправочник. Конечно, это для общих файлов, но когда вы помещаете каждую программу в свой префикс, они больше не делятся. Это приводит к тому, что программы не могут найти стандартные значки и тому подобное. GoboLinux справился с этим довольно уродливо: во время сборки $prefix/shareбыла символическая ссылка $prefix/Shared, а после сборки ссылка была указана на глобальный shareкаталог. Теперь он использует песочницу во время компиляции и перемещение файлов для работы share(и других каталогов), но ошибки при чтении ссылок все еще могут быть проблемой.

Наборы нескольких программ - еще одна проблема. GoboLinux никогда не заставлял GNOME работать полностью, и я не верю, что и в NixOS это так, потому что взаимозависимости компоновки настолько запеканы, что просто невозможно вылечить их всех.

Так что, да, это возможно , но:

• Достаточно много работы, чтобы просто заставить вещи функционировать.
• Некоторые программы могут просто никогда не работать.
• Люди будут смешно смотреть на тебя.

Все это может быть или не быть проблемой для вас.

¹ Версия 14.01 использует /System/Index, который отображается непосредственно на /usr. Я подозреваю, что будущая версия может отказаться от иерархии ссылок / индексов и использовать ее /usrпо всем направлениям.

² требуется /bin/shпо умолчанию.

И GoboLinux (который упоминал F.sb), и GNU guix являются дистрибутивами, которые используют структуру каталогов для каждого пакета вместе с символическими ссылками, указывающими на «текущую» версию двоичного файла.

GoboLinux кажется лучшим выбором, если вы хотите стабильную систему. GNU Guix явно говорит, что он еще не готов к производству. GoboLinux существует уже много лет. Я никогда не пробовал ни себя.

проверьте GoboLinux .

если вы хотите, чтобы структура каталогов была изменена, вы должны изменить некоторый код ядра, процесс загрузки, уровни запуска каталогов на основе rc-файлов и менеджер пакетов, а затем структуру каталогов.

Linux FHS основан на том, что Sun и другие компании UNIX решили в конце 1980-х годов.

В то время важным изменением было отказаться /usr/local/и ввести /opt// { bin! lib! man! ...}

Если вы ищете причину, по которой / usr / bin сегодня используется как полигон, я считаю, что GNOME - один из самых ответственных проектов.

То, что произошло с 32-битными и 64-битными библиотеками, похоже, вызвано FHS.

Solaris представила специфичные для платформы подкаталоги в /lib /usr/binи /usr/lib. Подумайте, как Sun усовершенствовала базовую концепцию с 1988 года.

Если каждый пакет имеет свою собственную часть файловой системы, вы должны были бы очень большими и громоздкими переменными окружения PATH, LD_LIBRARY_PATHи подобные.

Конечно, вы можете установить пакеты самостоятельно таким образом, а затем использовать что-то вроде модулей GNU для управления, находятся ли они в вашей среде или нет, и это то, что мы делаем для научного программного обеспечения, где я работаю, но мы не делаем это для программное обеспечение.