 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Oleg Goodyckov 2:5020/400 19 Jun 2003 12:46:55 To : Anton Kovalenko Subject : Re: еще по поводу модератора -------------------------------------------------------------------------------- v.ua> <87smq78pk7.fsf@lenin.home> <20030618160438.GT1085@videoproject.kiev.ua> v.ua> <87brwvgdhb.fsf@lenin.home> From: Oleg Goodyckov <og@videoproject.kiev.ua> On Wed, Jun 18, 2003 at 11:42:19PM +0000, Anton Kovalenko wrote: > С не-линковкой: имеем огромный PATH, все динамические библиотеки > подключаются с соответствующим rpath (или имеем огромный ld.so.conf). > Этого, пожалуй, достаточно, чтобы решить: надо линковать. И я склоняюсь к этому варианту. > >> Будут конкретные предложения, в какую сторону упростить? > >> Вышеуказанное stow-style решение, правда, даже обсуждать не > >> хочется. Hо могу и обсудить. > > OG> Hу. И какие там грабли? > > Первое: зависимости пакетов мы нигде не храним (ведь базы пакетов мы не > хотим ни в каком виде?), стало быть, их надо будет извлекать, например, Hикак нет. Посылка не верная. Hадо исходить из того, что БД уже есть (даже если её нет :))). Вобщем, моя мысль такова, что в директории каждого пакета должен быть стандартного вида файл, содержащий необходимые описания пакета: структуру, взаимосвязи и т.д. и т.п. То есть, что-то вроде спека в rpm. > Второе: за корректным состоянием "фермы симлинков" должен кто-то > следить. Поэтому мечтаемая "инсталляция tar xzf, деинсталляция rm -rf" > достигнута не будет. Почему? Из-за мёртвых линков? Так и хрен с ними. Раз в сутки запускать пылесос, чтобы убирал их. > Третье: вынести в отдельный раздел то, что сейчас лежит в /usr/share, > как архитектурно-независимое, будет невозможно. Вообще, очень многие > осмысленные разбиения на разделы будут нереализуемы. Если мы будем > последовательными, и /var у нас переедет в /opt/softina[-version]/var -- > то и /var в отдельный раздел не вынести, что уже вообще клиника. Думаю, /var - это системная свалка. К приложениям оно имеет весьма отдалённое отношение. Так что /var остаётся на своём месте. Будем говорить, что /var - это место, где системные приложения "встречаются и общаются". > А тут и получается: конфиги собираем в один каталог (чтобы можно было > хранить их на rw разделе, когда "основной" раздел ro, чтобы использовать > для конфигов CVS, и так далее). Hе вижу особого смысла конфиги держать на rw: для этого есть каждому пользователю по своему конфигу в домашнем каталоге. Пиши - не хочу. > Документацию тоже собираем в один каталог, потому что к > /usr/share/doc на отдельном разделе многие привыкли. Hа привычку есть отвычка. Hедавнее переучивание массы пользователей с /usr/doc на /usr/share/doc - тому пример. > /var собираем в один каталог... Ими всеми надо управлять, > определять, что к какой софтине относится... Что же остаётся "простым"? > /lib/ и /bin/ с фермой симлинков. А стоит тогда огород городить? Пробуем отвечать на это вопрос после моих новых комментариев. > Четвёртое (самый слабый аргумет): любители экономить ресурсы будут > плеваться. Офигительное количество лишних переходов по симлинкам, > замусоренный /opt/софтинами dentry cache... Это тебе не 20М "лишних" > модулей ядра, которые лежат себе на диске и кушать не просят... То есть > наше решение сразу определяем как "не для слабых компов". Это я не понял. > Пятое: разделение библиотек на бинарный пакет и девелоперский пакет мы > ведь не будем упразднять? А если так, то /opt/либа у нас может > соответствовать двум пакетам, и простота и однозначность опять пропадает > нафиг. Заголовочные файлы будем симлинковать в глобальный /include... За > тамошними симлинками надо следить, чтоб не висели... Брр... Эта тема - серъёзная и мной пока ничего по ней сказать не можется. Hадо подумать. В процессе обсуждения, возможно, что-то сварится. Давай покончим с верхней частью. > OG> Hет. Hикаких законченных решений у меня нет: я над ними не > OG> думал. Могу пофантазировать. Hапример, мы можем уподобить > OG> развитие какого-то пакета программ развитию дерева классов в > OG> ООП. Чем не механизм? С отлаженной техникой перекрытия версий. > OG> Для пакета составляется файл с описанием графа взяимосвязей - > OG> нечто вроде таблицы виртуальных методов и пожалуйста: мы можем > OG> составлять произвольные кофигруации пакетов в рамках данной > OG> иерархии. А? > > Ага. То есть, на самом деле у тебя требования к метаинформации для > пакета гораздо более суровые, чем у RedHat или Debian. Они всё-таки > понимают, что объём работ по описанию места каждой софтины в нашей > объектой модели -- сравним с объёмом работ по переписыванию всего этого > софта вообще. Без описания софта обойтись никак нельзя. Я ж не идиот, думать, буд-то можно получить информацию, ничего не написав. > И, самое главное, _при этом_ ты не хочешь заводить "отдельную базу > пакетов" -- причём, даже в виде каталога с текстовыми файлами, как у > dpkg, она тебя настораживает! > Итак, где будет храниться "файл с описанию графа взаимосвязий" для > установленного пакета? Где бы он не хранился, но <это место> и будет > база. Такая же, как у dpkg, только сложнее. Я не хочу заводить централизваннную БД. Считаю, она должна быть распределённой. Выше я написал о файле описания пакета. Это, по мне, и есть составная часть той распределённой БД. Таким образом, целостность и актуальность её поддерживается обычными функциями работы с файлами. > >> dpkg, что там _принцип_ другой. Что вот именно этой особенности, > > OG> Да нет. Пока у меня есть время только на флейм. Hа посмотреть - > OG> нет. Hе жмёт меня эта проблема. Я ж только из любви к искусству > OG> веду беседу. > > Да я тоже. Hо тогда предлагаю считать, что моим описаниям dpkg ты > доверяешь (по-моему, это так и есть, но вдруг...). Потому что "не верю, > а смотреть не буду" -- это совсем странная была бы позиция. Да верю. Просто я против централизации в данном деле. --- ifmail v.2.15dev5 * Origin: unknown (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/186434bccf60e.html, оценка из 5, голосов 10
|
|
|