раз все так плохо, отчего не поставить себе дебиан ? тебе же бинари хочется ? :) а про аргументы - доля правды есть, но еще много ты не дочитал, старайся

> Это - задача пакет манагера, отслеживание зависимостей etc, и он должен ее выполнять вне зависимости от организации файлопомойки на диске.

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

> Но если вдруг мне приспичило снести вот эту конкретную либу, и я отвечаю за то, что после этого все будет нормально - вот тут как раз rm замечательно сработает.

Во-первых, после этого таки надо запустить ldconfig. Во-вторых, зачем нужен этот закат Солнца вручную (TM). И наконец, чем хуже

dpkg --force-deps --purge libblah

> А он /var не трогает, он предлагает /usr раскидать.

1) А кто предлагал metadata перетащить в /opt/pkg/something ?

2) Весьма глупо он предлагает. Вместо /usr/bin -- тучу директорий /opt/blah/bin, вместо /usr/include -- /opt/blah/inlcude, вместо /usr/share/info -- /opt/blah/info, и т.п. А потом насиловать ядро, встроив в него, по сути, все ту же symlinks factory...

Нет уж, ну его в пень...

про ./configure

> Можно, но если сборка пакета состоит из ./configure --prefix=/opt/pkg-name

В таком варианте сборка состоит из

CPPFLAGS="-I/opt/foo/include -I/opt/bar/include -I/opt/blah/include" LDFLAGS="-L/opt/foo/lib -L/opt/bar/lib -L/opt/blah/lib" LD_LIBRARY_PATH=/opt/foo/lib:/opt/bar/lib:/opt/blah/lib ./configure --prefix=/opt/pkg-name --with-something-prefix=/opt/something

А посему -- ну его в болото.

> А если я хочу собрать и запускать не XMMS, а kreversi (ну нравится мне как она играет)?

То я ж и ругаюсь, что

1) у пЫонеров не всегда хватает ума отделить собственно софтину от GUI|TUI|CLI front-end'-a к ней (не говоря уж о том, чтоб написать bindings к скриптовому языку)

2) вместо стандартных Motif/Xaw имеем зоопарк toolkit'-ов, каждый из которых... не следует UNIX-way, мягко говоря.

> Т.к. base system package'ами не поставишь

Поставишь. Они, знаешь, еще "релизами" называются. Идешь и качаешь...

> Дык а зачем тогда весь этот базар-вокзал, про который автор статьи пишет? Какую проблему он пытается решить? И решает ли?

Имхо - четкое разграничивание пакетов. Чтоб сразу было понятно, что где. Хотя, согласен, сие не обязательно подразумевает раскладку по каталогам - в дженте работает qpkg, что-то там в дебиане. Ну, каждый извращается как может =)

> И наконец, чем хуже dpkg --force-deps --purge libblah

Помнишь, ты против реестра воевал в плане "нех плодить лишние сущности, everything is a file!". Вот тут имхо подход аналогичный - попытка свести решение проблемы к использованию на полную катушку стандартных unix-тулзов. Оправдано или нет - другой вопрос.

> 1) А кто предлагал metadata перетащить в /opt/pkg/something ?

Гм, а что оно вообще делает в /var? metadata - зависимости там всякие etc - вполне себе read-only. Кстати в тех же BSD Ports и Portage метаданные порта/портежа лежат в его каталоге, в /usr/port(s|age)

> Весьма глупо он предлагает. Вместо /usr/bin -- тучу директорий /opt/blah/bin, вместо /usr/include -- /opt/blah/inlcude, вместо /usr/share/info -- /opt/blah/info, и т.п.

С другой стороны, получаем неймспейсинг. Так что не все так плохо. Хотя юниксом тут определенно не пахнет.

А он у меня и есть. Просто есть еще и опыт поддержки FreeBSD. Печальный. Т.е. оно работало, но про геморройность я уже написал.

> В таком варианте сборка состоит из

Нет, поскольку он предлагает отображать все /opt/* в /usr/local. Так что достаточно будет -I/usr/local/include и -L/usr/local/lib. Правда, при таком отображении теряется имхо единственное действительно рациональное зерно во всем этом - неймспейсинг.

Ага, binary update системы является _НЕ рекомендуемым_. Не надо притворяться, что это не знаешь. А не рекомендуемый способ -- это значит в случае проблем я буду послан сразу и с чувством превосходства -- типа, как же, мы не рекомендовали, а ты поперся?

Ну здраствуйте... Хендбук цитировать?

motif и xaw - отстой прошлого века

ну и чего ж тебе надобно ? бинари-бейсед фрибсд ? ну дык твой дебиан любимый из него ядро выцарапал, и пытается применить свой классический подход. ссылку дать или это тоже "не алле" ? Просто, прежде чем писать про "дибилизм" сначала раберись где мухи, а где котлеты. Меньше эмоций, а больше размышлений. Это совет

Спасибо за совет -- я в общем стараюсь различать одно от другого. И знаю про дебиановский порт FreeBSD. Вот только не об этом речь -- а о тех людях, что свято уверены, что существующая во FreeBSD система хороша.

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

И, в качестве ответного совета, рекомендую ознакомиться на написанием слова "дебил". Оно пишется через Е, не через И.

> А посему -- ну его в болото.

Я тебя умоляю. Как раз при обсуждаемой схеме всё будет гораздо проще: -I/usr/local/include -L/usr/local/lib

> Правда, при таком отображении теряется имхо единственное действительно рациональное зерно во всем этом - неймспейсинг.

Имхо отображение нужно для одного: избавиться от туевой хучи строчек в ld.so.conf, путей в PATH, ключей -I, -L и прочего. То есть - костыль такой, исключительно ради того, чтоб удобней было.

Хм... Я, правда, не знаю. Перезагрузка - это я понимаю, если ядро обновляется, но single - что там такое есть, что надо донастраивать в нём, и чего нельзя сделать до перезагрузки? Я сам только cvsup-ом сижу на RELENG_4 начиная с 4_6_RELEASE и не помню чтобы когда-то надо было в single залазить после апдейта.

Интересная тенденция обсуждения на ЛОРе: придраться к выдранному из контекста куску, а затем, прикидываясь дебилом, активно делать вид, что кроме этого куска ничего больше не существует.

Видимо количество ума на планете действительно величина постоянная.

> и не помню чтобы когда-то надо было в single залазить после апдейта.

По-хорошему, рекомендуют делать installworld как раз в single.

> Нет, поскольку он предлагает отображать все /opt/* в /usr/local

1) А не порвется ж### отображать /opt/blah/include, /opt/blah/lib, /opt/blah/share, /opt/blah/bin, /opt/blah/info куда-то там в /usr/local/?

2) А во что отобразятся /opt/gcc-3.3/bin/g++ и /opt/gcc-3.4/bin/g++ ?

> Правда, при таком отображении теряется имхо единственное действительно рациональное зерно во всем этом - неймспейсинг.

В том-то и дело, что рациональность его весьма сомнительна.

> 1) А не порвется ж### отображать /opt/blah/include, /opt/blah/lib, /opt/blah/share, /opt/blah/bin, /opt/blah/info куда-то там в /usr/local/?

Судя по всему - не порвётся.

> 2) А во что отобразятся /opt/gcc-3.3/bin/g++ и /opt/gcc-3.4/bin/g++ ?

А это уж как выберешь. Читай внимательнее. Захочешь - в /usr/local будет 3.3, захочешь - 3.4. Захочешь вызвать то, чего там нет - пойдешь себе в "/usr/blah/bin/g++".

Не прикидывайся дебилом.

> 1) А не порвется ж### отображать /opt/blah/include, /opt/blah/lib, /opt/blah/share, /opt/blah/bin, /opt/blah/info куда-то там в /usr/local/?

Делается одной командой: mount [вставить нужные ключи] /opt/blah /usr/local

И так - для каждого blah. И не нужно делать отдельный mount на bin, share, info и прочее г*вно.

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

Кошку у тебя, видимо, зовут dpkg, а собаку - apt-get...

"КЮ - допустимое в обществе ругательство. КУ - все остальные слова".

стандартные?

> Вот тут имхо подход аналогичный - попытка свести решение проблемы к использованию на полную катушку стандартных unix-тулзов.

Ни разу не стандартные... И спорно, что UNIX...

> Гм, а что оно вообще делает в /var? metadata - зависимости там всякие etc - вполне себе read-only.

Неверно. Зависимости частенько меняются.

> Кстати в тех же BSD Ports и Portage метаданные порта/портежа лежат в его каталоге, в /usr/port(s|age)

Это одна из основных причин того, что ни тот, ни другой не умеет толком сделать dist-upgrade _из бинарных пакетов_.

> С другой стороны, получаем неймспейсинг.

Не получаем. База данных о зависимостях и package manager все равно нужны.

> Неверно. Зависимости частенько меняются.

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

У вас часто меняются зависимости уже установленных пакетов, тов. Дебил?

Хотя, что я спорю. В профиле на Dselect видна следующая информация:

ID: 7357 Nick: Dselect Полное имя: stupid idiot

То есть, из полного имени следует тот факт, что спорить с чем-то подобным бесполезно.

В общем-то, да, согласен, в теории installworld и mergemaster стоило бы в single делать, но, на практике, мне, лично, сложно представить что такого ужастного может случиться, если делать это в обычном режиме, при условии что всё равно потом перегружаться собрался.

У меня тип один знакомый, вот, вообще, однажды /etc удалил полностью по дури - система без /etc проработала целый день, пока восстановили :-))

солнце, воздух и вода не помогут никогда...

Укрепляет организм лишь спортивный *изм...

> Делается одной командой: mount [вставить нужные ключи] /opt/blah /usr/local

Да-да, и так 800 раз... И чего ради? Не говоря уж о том, что VFS так не умеет (и хвала Богам, бо иначе ему быстренько станет плохо).

> Они не меняются в пределах одной версии конкретного бинарного пакета. Появился другой - дык это уже другой пакет, который тащит с собой свои зависимости.

Нет, это тот же самый пакет _другой версии_. Как я уже говорил, именно поэтому APT умеет делать обновление, а порты -- нет.

> Да-да, и так 800 раз...

А у тебя 800 пакетов? Да ну :-)

И что-то ты плохого мнения о подсистеме VFS. Как раз с этим она вполне себе справляется.

> Нет, это тот же самый пакет _другой версии_.

Какая разница как это называть, сказочный вы наш. Назовём это другой инстанцией.

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

Третий раз повторять не буду - может прекратите играть в дебила?

> У вас часто меняются зависимости уже установленных пакетов, тов. Дебил?

Во-первых, я Вам не товарищ. А во-вторых, при переходе на новый gcc, при обновлении библиотек (таком, что меняется soname), просто при выходе новой версии софтины, etc.

шайбу! шайбу!

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

Система управления пакетами как раз и предназначена, чтоб автоматически обновить весь имеющийся софт, при этом корректно обработав зависимости (добавить новые пакеты, удалить те, которые больше не нужны). Поделка, которая этого не умеет, идет в сад.

P.S.

Даешь каждой версии каждой софтины свою директорию!

Под руководством мудрой системы портов семимильными шагами в DLL hell!

> Во-первых, я Вам не товарищ.

Хорошо, буду называть вас по имени, уважаемый stupid idiot. Более того, вы сами этим именем подписались - так что вроде бы всё в порядке.

> А во-вторых, при переходе на новый gcc

При переходе на новый blah, при выходе нового blah и т.п. - все эти blah ставятся уже в новые директории, правда? Вы демонстрируете поразительную невнимательность (либо нежелание замечать, что вам говорят)... Или просто охота пофлеймить, неважно по какому поводу? :-)

> семимильными шагами в DLL hell!

Про зависимости здесь уже достаточно сказано, кому нужно - поймёт.

А DLL hell, уважаемый stupid idiot, творится в вашем мешке с г*вном, который вы тоже, видимо, называете системой. Только вы это упорно скрываете - видимо, от стыда.

> Да-да, и так 800 раз...

$ rpm -qa | wc -l 810

> И что-то ты плохого мнения о подсистеме VFS. Как раз с этим она вполне себе справляется

С восмистами обысными mount'ами может и справится, но с восьмистами union-mount'ами НЕ справится - падение производительности будет диким, либо будет жестокий расход памяти ядром (метров от 20).

DLL hell в той или иной форме - это реалии жизни. Что лучше - иметь красиво установленную библиотеку строго одной версии и при этом половину неработающего софта, или всё-таки мириться с наличием нескольких версий ради того чтобы всё работало? Кто может поручитmся за 100% совместимость разных версий библиотек, которые писал кто-то другой, да ещё и "just for fan"?

2Ron: понимаю людей, которые пишут софт чтобы поразвлечься, но чтобы писать за вентилятор... :-)

:-))

Не знаю, за что они там пишут, но, для меня, например, загадка, почему проги написанные для GTK необходимо не просто пересобирать (по уму даже этого должно не требоваться), а переписывать для GTK2. Точнее, мне понятно, почему, просто непонятно - кому захочется при этом всерьёз делать что-либо под GTK2, если по чьему-то хотенью могут завтра слепить GTK3 под который тоже придётся всё переписывать?

сынок, Деда Мороза нет! (С)

> При переходе на новый blah, при выходе нового blah и т.п. - все эти blah ставятся уже в новые директории, правда?

Какого черта? На кой мне 10 версий одной и той же библиотеки | программы? (Если вдруг мне это понадобится, я явно это укажу).

> Вы демонстрируете поразительную невнимательность (либо нежелание замечать, что вам говорят)...

А Вы демонстрируете нежелание подумать, прежде чем сказать что-либо.

> DLL hell в той или иной форме - это реалии жизни. Что лучше - иметь красиво установленную библиотеку строго одной версии и при этом половину неработающего софта,или всё-таки мириться с наличием нескольких версий ради того чтобы всё работало?

Лучше собирать несовместимые версии библиотеки с разными soname.

См. http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

> Кто может поручитmся за 100% совместимость разных версий библиотек, которые писал кто-то другой,

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

> почему проги написанные для GTK необходимо не просто пересобирать
> (по уму даже этого должно не требоваться), а переписывать для GTK2

ЧЕГО??? Сейчас специально пересобрал notebook и calendar в из gtk1 под gtk2. notebook заработал сразу, в calendar достаточно заменить выбор шрифта. Похоже, что уважаемому сэру нужно меньше надо читать всякие "колонки золотова" и "рыбные дни"?

>> Лучше собирать несовместимые версии библиотеки с разными soname.

А с несовместимыми хедерами как быть?

>> Сейчас специально пересобрал notebook и calendar в из gtk1 под gtk2.

XMMS ? :-)

А в чём, собственно вообще тут `hell'?

Ну стоит, допустим, несколько разных версий библиотеки - каждая в своём каталоге /usr/local/bla-bla-bla/version. Какая прога с какой собрана - той и пользуется. В чём тут `hell'?

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

> А с несовместимыми хедерами как быть?

Именовать по разному ( в т.ч. -- раскидывать по разным директориям). Кстати, те костыли, которые автор предлагает, в данном случае только ухудшают ситуацию.

> Ну стоит, допустим, несколько разных версий библиотеки - каждая в своём каталоге /usr/local/bla-bla-bla/version. Какая прога с какой собрана - той и пользуется. В чём тут `hell'?

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

слушай дава не будем, а ? про святоуверенных и непосвященных :) Все , что ты тут подобными аргументами пытаешься доказать - ничто иное как избитое "рулит/сосет". Правда посмешнее будет, чесслово. Ты не сноб, безусловно, ты же снисходишь до разговора с этими самыми несчастными, даже вон ошибки исправляешь :) Бинари не панацея от всех бед, и мне жаль, что ты об этом даже не задумывался. Ну да ладно... :)

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

Если они их ещё при этом будут пытаться в одно и то же место сложить - то от этого будет только хуже.

Софт стал сейчас сильно сложный. Привычный юниксовый hier с bin и lib придумали ещё когда awk, наверное, был самой сложной прогой. А сейчас каждая прога тянет за собой с полсотни библиотек.

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

Надеяться, что дистроклепатели всё это разрулят - что же это, тогда получается - что нельзя спокойно поставить прогу о которой они не позаботились? Это уже выходит даже похлеще, чем интеграция IE в виндоус...

Я не стал бы говорить, что аналог "Program Files" есть вечный рулез и решение всех проблем, но обычный bin-lib-include тоже, уже, мягко говоря, не отвечает современным реалиям.

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

Пошёл нахуй.