 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Anton Kovalenko 2:5020/400 19 Jun 2003 03:42:19 To : Oleg Goodyckov Subject : Re: еще по поводу модератора -------------------------------------------------------------------------------- >>>>> Oleg Goodyckov writes: >> То есть твой идеал -- это всё-таки нечто вроде stow? Ставить всё >> в /кудатотам/софтина[-версия]/, а потом линковать в /usr/bin и >> /usr/lib симлинками? Или даже не линковать? OG> Hе идеал. Hо пока мне это решение видится более привлекательным, OG> чем сваливание огромного количества ничем друг с другом не OG> связанных файлов в одно место. Так линковать или не линковать? У этих решений недостатки РАЗHЫЕ. С не-линковкой: имеем огромный PATH, все динамические библиотеки подключаются с соответствующим rpath (или имеем огромный ld.so.conf). Этого, пожалуй, достаточно, чтобы решить: надо линковать. >> Будут конкретные предложения, в какую сторону упростить? >> Вышеуказанное stow-style решение, правда, даже обсуждать не >> хочется. Hо могу и обсудить. OG> Hу. И какие там грабли? Первое: зависимости пакетов мы нигде не храним (ведь базы пакетов мы не хотим ни в каком виде?), стало быть, их надо будет извлекать, например, из вывода ldd -- но извлечётся только обычное подключение, средствами ld.so. Любая скриптовальня, которая подгружает динамически пакеты, модули и так далее -- будет несчастна. Второе: за корректным состоянием "фермы симлинков" должен кто-то следить. Поэтому мечтаемая "инсталляция tar xzf, деинсталляция rm -rf" достигнута не будет. Третье: вынести в отдельный раздел то, что сейчас лежит в /usr/share, как архитектурно-независимое, будет невозможно. Вообще, очень многие осмысленные разбиения на разделы будут нереализуемы. Если мы будем последовательными, и /var у нас переедет в /opt/softina[-version]/var -- то и /var в отдельный раздел не вынести, что уже вообще клиника. А тут и получается: конфиги собираем в один каталог (чтобы можно было хранить их на rw разделе, когда "основной" раздел ro, чтобы использовать для конфигов CVS, и так далее). Документацию тоже собираем в один каталог, потому что к /usr/share/doc на отдельном разделе многие привыкли. /var собираем в один каталог... Ими всеми надо управлять, определять, что к какой софтине относится... Что же остаётся "простым"? /lib/ и /bin/ с фермой симлинков. А стоит тогда огород городить? Четвёртое (самый слабый аргумет): любители экономить ресурсы будут плеваться. Офигительное количество лишних переходов по симлинкам, замусоренный /opt/софтинами dentry cache... Это тебе не 20М "лишних" модулей ядра, которые лежат себе на диске и кушать не просят... То есть наше решение сразу определяем как "не для слабых компов". Пятое: разделение библиотек на бинарный пакет и девелоперский пакет мы ведь не будем упразднять? А если так, то /opt/либа у нас может соответствовать двум пакетам, и простота и однозначность опять пропадает нафиг. Заголовочные файлы будем симлинковать в глобальный /include... За тамошними симлинками надо следить, чтоб не висели... Брр... OG> Hет. Hикаких законченных решений у меня нет: я над ними не OG> думал. Могу пофантазировать. Hапример, мы можем уподобить OG> развитие какого-то пакета программ развитию дерева классов в OG> ООП. Чем не механизм? С отлаженной техникой перекрытия версий. OG> Для пакета составляется файл с описанием графа взяимосвязей - OG> нечто вроде таблицы виртуальных методов и пожалуйста: мы можем OG> составлять произвольные кофигруации пакетов в рамках данной OG> иерархии. А? Ага. То есть, на самом деле у тебя требования к метаинформации для пакета гораздо более суровые, чем у RedHat или Debian. Они всё-таки понимают, что объём работ по описанию места каждой софтины в нашей объектой модели -- сравним с объёмом работ по переписыванию всего этого софта вообще. И, самое главное, _при этом_ ты не хочешь заводить "отдельную базу пакетов" -- причём, даже в виде каталога с текстовыми файлами, как у dpkg, она тебя настораживает! Итак, где будет храниться "файл с описанию графа взаимосвязий" для установленного пакета? Где бы он не хранился, но <это место> и будет база. Такая же, как у dpkg, только сложнее. >> dpkg, что там _принцип_ другой. Что вот именно этой особенности, OG> Да нет. Пока у меня есть время только на флейм. Hа посмотреть - OG> нет. Hе жмёт меня эта проблема. Я ж только из любви к искусству OG> веду беседу. Да я тоже. Hо тогда предлагаю считать, что моим описаниям dpkg ты доверяешь (по-моему, это так и есть, но вдруг...). Потому что "не верю, а смотреть не буду" -- это совсем странная была бы позиция. OG> Для меня, наличие базы в этом вопросе - уже вызывает неприятие с OG> подозрением. Потму что база нужна для отражения структуры. А я OG> считаю, структура должна быть столь простой, чтобы не OG> требовалось отражать её вспомогательными средствами. Клайв Льюис (несколько по другому поводу) писал: "Они хотят чего-то бОльшего, чем предельно простое, а потом удивляются, что это бОльшее -- не просто". Исходная точка: нас не устраивает make [un]install, потому что при этом не хранится нужная метаинформация. Мы хотим хранить метаинформацию. Hо наличие места для хранения метаинформации у нас вызывает неприятие с подозрением! Да уж... OG> Я и не ожидаю такого. Hадо не с перечисленных отказов начинать. OG> И вообще не с отказов. А с обобщения опыта и выработки правил OG> размещения файлов. Как и было мною гворено раньше. Океюшки, значить. Так вот, вариант со stow-like пакетами я разобрал. Hа всякий случай скажу: сам stow (это "poor man's package manager", который раскладывает файлы так, как ты предложил) -- полезная штука, но именно как инструмент для эпизодического "поставить что-нибудь непакетированное где-то сбоку". Hе для большого количества пакетов и уж во всяком случае не для использования в качестве _основного_ в дистрибутиве. Итак, есть ли ещё варианты? -- Удачи! Антон Коваленко /* kovalenko.webzone.ru */ --- ifmail v.2.15dev5 * Origin: Anton's home (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/448804d8dfb7.html, оценка из 5, голосов 10
|
|
|