Что нового будет в третьей версии Filesystem Hierarchy Standard?

> а как ты предлагаешь раздавать права на эту мешанину данных, библиотек и программ?

Он щас тебе предложит прикрутить какой-нить костыль с контекстами безопасности, которые задает системный администратор с помощью специальной утилиты. Привет венда.

> Только не надо мне сказки рассказывать про lib*.so, потому что они разных версий прекрасно живут в /lib и /usr/lib.

libsomething.so.1.1 и libsomething.so.1.2 живут не то, чтобы очень хорошо.

> libsomething.so.1.1 и libsomething.so.1.2 живут не то, чтобы очень хорошо.

Слинковаться с правильной версией, ld все разрулит. Если нет, ткни носом, плз, где я ошибаюсь.

>libsomething.so.1.1 и libsomething.so.1.2 живут не то, чтобы очень хорошо.

Версия у них одна и та же - «1»

> Версия у них одна и та же - «1»

Версия одна, библиотеки разные. Проблема.

>Версия одна, библиотеки разные. Проблема.

Библиотека одна - libsomething.so.1 - именно это имя используется при загрузке.

>> libsomething.so.1.1 и libsomething.so.1.2 живут не то, чтобы очень хорошо.

Слинковаться с правильной версией, ld все разрулит.

Ты слинковал программу с libsomething.so.1.1, линковщик прописал soname libsomething.so.1; потом libsomething обновился до версии 1.2, в которой что-то исправили или сломали (но soname остался libsomething.so.1), и твоя прога не работает; если найдется программа, которой нужна именно libsomething 1.2 (и она не работает с более ранней версией из-за багов или фиксов), ты в тупике.

>>Версия одна, библиотеки разные. Проблема.

Библиотека одна

А, ну как скажешь.

>обновился до версии 1.2, в которой что-то исправили или сломали

Если сломали - беги в багзиллу. Потому как ломание обратной совместимости API/ABI без смены сонейма запрещена.

>> обновился до версии 1.2, в которой что-то исправили или сломали

Если сломали - беги в багзиллу.

А еще нужно написать в Спортлото

Потому как ломание обратной совместимости API/ABI без смены сонейма запрещена.

Исправление ошибок - тоже?

Ситуацию понял, спасибо.

А разве по умолчанию будет искаться не полное совпадение имени библиотеки? Если будет найдет object для libsomething.so.1.1, то ld будет использовать именно его, нет?

По идее, проблема решается существованием пакета libsomething с либой последней версии с /lib/libsomething.so{,1.2} с soname на libsomething.so.1 и еще одного пакета libsomething1.1 со старой версией.

>Исправление ошибок - тоже?

Исправление ошибок (как и добавление функциональности в библиотеку, в т.ч. разширение API) без ломания обратной совместимости API/ABI можно и нужно делать без изменения сонейма. //KO

PS: Подход уродский, но это только на экстренный случай.

> А разве по умолчанию будет искаться не полное совпадение имени библиотеки?

По умолчанию ищется so-файл, имя которого совпадает с soname библиотеки. В нашем случает soname - libsomething.so.1

По идее, проблема решается существованием пакета libsomething с либой последней версии с /lib/libsomething.so{,1.2} с soname на libsomething.so.1

Ты предлагаешь выпустить библиотеку с новым soname только для того, чтобы исправить описанную проблему? На это никто не пойдет.

Gobo это такой mac os с линукячьим лицом? :) Оно вообще живое?

Это лучше, чем старые либы без апдейтов :}

Это всё детали, вполне решаемые.

Так или иначе, но это ещё одна причина переходить на Plan 9.

>Игры планируется размещать по следующей схеме: /usr/bin для бинарных файлов, /usr/share для ресурсов игры и /var/lib для тех компонентов, которые должны быть доступны на случай наличия нескольких учётных записей в системе. Старая схема предполагала размещение игр и их компонентов в отдельных каталогах /usr/games и /var/games.

Какую лажу опять придумали для игр линуксоиды:( Намного лучше все игровые ресурсы, библиотеки и прочие бинарники размещать в /usr/share/собственный_каталог_игры_для_всего_что_надо. Для игры несколькими учётными записями существуют каталоги /home/user/.каталог_игры. А в /usr/bin если по уму, то надо класть лишь исполняемый скрипт, который запустит игру. Опера нормально запускается через баш скрипт и игры так тоже могут.

> а кто будет определять эти спец. пространства

Админ при помощи пакетного менеджера.
Грубо говоря, будет что-то типа:

# apt-ns create testing1 --clone base
# apt-ns create testing2 --clone base
# apt-get install kde4.6 --namespace testing1
# apt-get install kde4.7 --namespace testing2
# chrootns testing1
# su -l username
username:~$ юзаем kde 4.6
.
.
.
username:~$ ^D
# chrootns testing2
# su -l username
username:~$ юзаем kde 4.7

А кто сказал, что /media и /var между этими пространствами совместимы между собой?

Админ сказал. Если /var потребуется другая, значит, её тоже виртуализуем.

Тебе что, никогда не приходилось плясать с chroot, bind-ами и установкой пакетов в chroot-системе, чтобы создать какое-нибудь тестовое окружение? Уже хотя бы для автоматизации такой задачи стоит создать пакетник, который всё это будет уметь сам. Тем более, что этим его ништяки не ограничиваются: можно создать отдельные наборы установленных программ для разных юзеров, можно без перекомпиляции поставить и заставить работать конфликтующие пакеты, можно использовать пространства имён для атомарного отката между обновлениями системы. Куча преимуществ.

Ты мне напоминаешь такого чувака, который возмущается «пакетные менеджеры — зло! всю жизнь софт ставили при помощи ./configure && make && make install, и всё работало! а кто сказал, что пакеты, устанавливаемые менеджером совместимы? Машина не заменит человека! Только хардкор, только ручная установка!»

Вот откуда вы столько травы берете и трава ли это?!

Это хорошие, годные грибы.

поправка: c:\users\ D&S выглядело убого даже для винды

> Если сломали - беги в багзиллу. Потому как ломание обратной совместимости API/ABI без смены сонейма запрещена.

Мне не нужна рабочая система через 2 недели. Мне нужна рабочая система здесь и сейчас.

> а как ты предлагаешь раздавать права на эту мешанину данных, библиотек и программ?

А как ты раздаешь права на файлы в FHS?

Собственно, менеджеры пакетов для того и придуманы, чтобы не скатываться к примитивному, насквозь устарелому program files.

Точно. А теперь давай ты сделаешь следующий шаг и осознаешь, что менеджеры пакетов можно использовать и не для одного пространства имён, а для нескольких.

Я и не несу пургу. И я знаю, чем /bin отличается от /sbin. И не вижу никакого смысла разделять их содержимое. Все равно «обычный» пользователь частенько выполняет утилиты из /sbin.

Если слово «ориентировать» вызывает у вас сортирные ассоциации то вам к доктору.

Ты вообще в курсе, зачем /usr/local нужен?)

Совершенно не в курсе. Не нужен он!

тут я пожалуй соглашусь, но ситуации всякие бывают...

На сервере вы тем более никогда не переполните корень (если, конечно, не будете в него пихать /tmp, /var, всякие пользовательские данные и т.п.) Для сервера 1ГБ по уши достаточно.

> Пофиг на «засрём корень», а вот то что / в ro не смонтируешь это плохо.
/run предполагается делать в tmpfs вроде как

/packages/${pkgname}/${pkgversion}

Один я подумал про /usr/portage/?

Только зачем эту и другие абстракции делать основными и выполненными в виде файловой системы? Пусть внутри приложения, которому нужна такая структура, всё отображается в нужном ему виде

> Один я подумал про /usr/portage/?

Ну и при чем тут портаж?

Только зачем эту и другие абстракции делать основными и выполненными в виде файловой системы? Пусть внутри приложения, которому нужна такая структура, всё отображается в нужном ему виде

Приложениям не нужны ${pkgname}/${pkgversion}. Приложение должно видеть FHS. ${pkgname}/${pkgversion} для _хранения_ _пакетов_.

Я может пишу не по-русски?

Ну и при чем тут портаж?

Там вроде как раз ${pkgname}/${pkgversion}(хотя последнее там только в окончаниях имен ебилдов). Хотя пакетный менеждер один фиг заводит себе БД. Если это аналог файловой системы, почему она должна виртуализироваться и быть в «корне»? Можно же, как в генте, положить в один из каталогов. Если бы сейчас шел 92 год и они бы разработали стандарт каталогов пакетного менеджера, то современного разброда бы не было. Может, даже только одна система управления пакетами бы выжила. А теперь уже ничего не изменить

> Совершенно не в курсе. Не нужен он!

Ты просто не знаешь, зачем он нужен :)

На сервере вы тем более никогда не переполните корень (если, конечно, не будете в него пихать /tmp, /var, всякие пользовательские данные и т.п.) Для сервера 1ГБ по уши достаточно.

Добавь веб-сервер в список к тому десктопу, ага.

«Мне не нравится, что бинарики лежат в двух папках а не одной, правда я этого не замечаю потому что есть $PATH, НО Я ВСЁ РАВНО НЕДОВОЛЕН!» - только ради этого глупо жертвовать гибкостью такой иерархии файлов, какая имеется сейчас.

И вообще, если не нравится FHS. Будь мужиком, создай симлинки.

> Там вроде как раз ${pkgname}/${pkgversion}

Там ебилды лежат. При чем тут пакеты?

Ты шо тугой такой? он тебе про иерархию говорит. В принципе да, иерархия могла бы выглядеть, как дерево портежей, это намного удобнее.

Иерархия чего? Телепаты в отпуске.

А в чем разница? Пакетный менеждер работает с упорядоченным набором сущностей, каждая либо из которых знает, где лежат исходники/бинарники в случае source-based дистра, либо является совокупностью метаданных и самой информации

>Иерархия чего?

Файловой системы. То, что ты предлагал в стиле ${pkgname}/${pkgversion}

http://www.linux.org.ru/jump-message.jsp?msgid=6567793&cid=6572195

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

> Файловой системы. То, что ты предлагал в стиле ${pkgname}/${pkgversion}

Это вообще не иерархия, это просто пакеты. Концептуально, там может быть хоть ${pkgname}/${pkgversion}, хоть $(md5sum pkg.tar.gz) — главное, чтобы содержимое отдельных пакетов лежало в отдельных каталогах, идентифицируемых пакетным менеджером.

>Это вообще не иерархия

главное, чтобы содержимое отдельных пакетов лежало в отдельных каталогах

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

> Всё хорошо, но я не пойму твоего упорного желания видеть это всё в виде каких-то виртуализированных слоёв.

Опиши уже своё видение правильной организации пространства имён, чтобы разговор стал предметным. Не парь, пожалуйста, мозги, краткими замечаниями, которые порою невозможно распарсить.

>Опиши уже своё видение правильной организации пространства имён, чтобы разговор стал предметным

Обязательно, но несколько позже.

> Куда ты хочешь впиливать эти «отдельные каталоги», если не в иерархию?

В иерархию, да. В FHS. Установка пакета в пространство имён сводится к размещению симлинков на файлы пакета. Удаление — удалению симлинков. (Технически это могут быть и несимлинки, а какие-нибудь юнионы или другие средства, концептуально это не важно, опять же.)

>В иерархию, да. В FHS. Установка пакета в пространство имён сводится к размещению симлинков на файлы пакета. Удаление — удалению симлинков

Не далее, как вчера, ты проклинал линки, называя их костылями. Я уже окончательно запутался.

круто, конечно. А как же «слоты» в той же генте? Кажется, слишком много телодвижений для простого назначения разных версий программ разным пользователям. Проще тогда каждому по вирутальной машине выделить:)

Будь мужиком, создай симлинки.

Не годится: пакетный менеджер не будет их обновлять.

> Не далее, как вчера, ты проклинал линки, называя их костылями. Я уже окончательно запутался.

Я более говорил о bind + chroot, называя их костылём для виртуализации пространств имён, нежели о симлинках. Когда мы говорим о реализации, это костыли. Но более подходящих средств у нас под Linux нет. Хотелось бы видеть хотя бы поддержку вычислимых контекстно-зависимых симлинков, чтобы избежать кучи bind-ов.

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

>А как ты раздаешь права на файлы в FHS?

в соответствии с их содержимым. Пра можно раздавать не только на файлы, но и на директории и даже разделы. А если там мешанина, то и права получаются запутанными.

Точно. А теперь давай ты сделаешь следующий шаг и осознаешь, что менеджеры пакетов можно использовать и не для одного пространства имён, а для нескольких.

Да бы бы смысл. Чрут в rpm есть c незапямятных времен и даже используется, но нафига это в обычной системе?

> А если там мешанина, то и права получаются запутанными.

Схренали в FHS будет мешанина? Правда, ты не сможешь назначить отдельно права те элементы, которые являются симлинками, но — специально для такого случая можно даже предусмотреть установку не в виде симлинков/хардлинков, а копированием файлов, как в обычных пакетниках. Такой частный случай работы, сводящий «умный» пакетник в «классический». Хотя я правда не знаю, заем это может понадобиться. На всё, что лежит в /lib, /*bin, /usr, нет никакого смысла менять права — это же просто код + вспомогательные ресурсы.

но нафига это в обычной системе?

Например, я тестирую сборку пакетов в чистой системе.

> Админ при помощи пакетного менеджера.

Грубо говоря, будет что-то типа:

# apt-ns create testing1 --clone base
# apt-ns create testing2 --clone base
# apt-get install kde4.6 --namespace testing1
# apt-get install kde4.7 --namespace testing2

а при помощи ФС со снапсшотами на запись эту проблему решить можно? типа ZFS или BTRFS?

псевдо-команды: # create snapshot test1 --clone base # create snapshot test2 --clone base # chfs test1 # apt-get install kde4.6 # chfs test2 # apt-get install kde4.7

тогда и пакетный менеджер работает как сейчас и у вас реально разные окружения - test1 & test2

PS с снапшотами на запись не работал.