Fedora Core 6 test 1

>А накоя мне *86_64 на моём 32битном атлонике?

>10.1 пашет быстро жрать не просит. Работаю - кучу прог запущено, плюс апач и самба - занято всегда меньше 512 метров оперативки.

А мне вот на моем x86_64 очень даже нужна. Или предлагаешь мне его продать и купить 32-битный или ставить 32-битные линуха?

>Видишь ли, в RedHat apache зависит от XFonts, XFonts от XOrg сервера, а последний, очевидно, от KDE || GNOME.

А если не говорить того, чего не знаешь, было бы замечательно. Иксы ставятся отдельно легко. И причем не в полном составе.

>Это ты на их сайте прочитал? последний gcc не собирает половину софта, так что что-то не верится, что они не используют gcc-3.4.

В fedora весь софт собирается последним gcc. Для этого часть софта пропатчена.

Для совместимости поставляется более старый gcc.

>Вот поэтому то я и говорю, что ставить bleeding edge, коим является FC, в production как минимум неразумно.

Естественно, но видимо в некоторых частях можно или нет альтернативы.

> А с каких пор kpdf работает без KDE?
Без kdebase? Вполне себе работает.
> Остальное да, собирается по максимуму.
Имелась в виду практика прописывания в Requires: всего что надо и не очень. Отсюда искусственно созданная привязка к именам пакетов, а не только библиотек и их версий (с чем rpm сам справляется неплохо).

Не знаю как у остальных, а у меня в 5й федоре сразу после установки не запускались графические конфигуралки, жалуясь на глюки с локалью...(выбрал koi8-r)...после чего сие поделие было отправлено в /dev/ass

> Не знаю как у остальных, а у меня в 5й федоре сразу после установки не запускались графические конфигуралки, жалуясь на глюки с локалью...(выбрал koi8-r)...после чего сие поделие было отправлено в /dev/ass

FC5 с локалью KOI8-R работает без проблем. Проверено лично.

>FC5 с локалью KOI8-R работает без проблем. Проверено лично.

Сто пудов.

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

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

>Имелась в виду практика прописывания в Requires: всего что надо и не очень. Отсюда искусственно созданная привязка к именам пакетов, а не только библиотек и их версий (с чем rpm сам справляется неплохо).

Они собирают даже wine с sane и поддержкой gphoto. Именно поэтому тот же wine тянет всю эту хрень. Но если ее не поставить, то wine не запустится.

С другой стороны, ставим mplayer и xdtv - и все, у нас практически полный набор кодеков и библиотек видеовывода. Добавляем к ним -devel пакеты и можно собирать любую штуку, не матерясь после каждого ./configure на отсутствующие кодеки.

> Какок FC гогно, я понял спрыгнув на SUSE. Косяки тоже есть, но не как в этой вечной бете.

ничего, через годик можно будет уже спрыгивать и на Gentoo ;)

А вообще если жить в реальном мире особо не попрыгаешь. Пришлось юзать FC, потому как нужный IBM софт под неё сертифицирован, а под клевый Gentoo - фигвам, пришлось бы работать напильником и никакого супорта .. и чего ради?

> завтра утром выложу, дома debian sarge

как и обещал

http://darkmachine.org/~artem/add_remove.png

> P.S. А сильно был нужен rhgb?

дык красиво же

> > Ну а если смотреть на слаку - что, религия не позволяла ядро пересобрать? ;)

> а rhgb не отвалится? оно вроде бы где то в initrd

Оно НЕ в initrd - так что не отвалится. FC5, ядро 2.6.176 "ванилла" - rhgb живет и не тужит.

>>Requires: packageA || packageB

>А ты мне покажи такую программу, где при сборке можно указать такую зависимость.

Попадалось, уж поверь:)

>меняя зависимости, ты собираешь под себя.

Почему "меняя"? почему "под себя"?:) Чаще "устанавливая" и "не для себя только".

>То major-апдейт, такие обновления (даже больше - такие софтины) на серваке недопустимы.

Три безосновательных утверждения в одной фразе - круто!:)))

>А зачем вообще часто и массово обновлять внутренние серверы предприятия.

Сначала ты свёл компы только к серверам, теперь сервера - к "внутренним серверам".

>втыкается вообще автоматом с внутреннего сервера обновлений.

Это к чему вообще приплетено?

>Скажем так - "ебилд = скрипту Bourne-shell, в котором есть ссылки (через переменные) на внешние функции-переменные", спек - та же самая фигня, только интерпретируется rpm-ом вместо шелла... принципиальных отличий, кроме requires/depend и тучи камментов в хвосте у спеков от слакбилдов нет в принципе :)

Вот как раз из-за подобного бреда я сказал, что ты не представляешь "что такое спеки/ебилды и чем оно отличается от просто сырцов и патчей"

>Задача одна - автоматизация сборки.

С autotools/scons/etc. перепутал:)

>Спеки генерятся почти автоматом? Если это так, то это круто :)

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

>> Если "сервак" - то это значит, что я могу установить быстро множество "серваков", с разным набором сервисов и "не забыть установить все нужные либы" и "не держать всё это в голове":) >Так быстро = времени на tar cv | tar xf -, либо на мирроринг dd'ом, с установкой и настройкой только 1 машины, плюс потом пакетное изменение конфигов по ssh, если сильно такое нужно.

Угу. "Только одной машины" - это у тебя. С таким подходом тебе больше и "не светит". "С разным набором сервисов" и под разные задачи - не асилил? Объясняю: сервера - они вообще-то разные бывают, для разных задач и т.п.

>"Быстро ставящийся сервер"? Зачем?

:)))))))) Просто нет слов:) Пошли уже аргументы: "медленно выполненная работа лучше, чем быстро выполненная". "- За сколько сделаешь? - Ну, за день.... - А за неделю сможешь? - Ну, тут без помошника не обойтись..." (с) "Граф Калиостро":)))

>Так и у меня так - поставил, апдейтнул, клонировал, запустил-протестил, забыл.

Клонируй-клонируй... Если у тебя все (все один?) компы выполняют одно и то же...

>В автоматическом отслеживании зависимостей конечно множество плюсов... но хочется, чтобы минусов не было вообще :)

"Минусы" - в студию!

> последний gcc не собирает половину софта, так что что-то не верится, что они не используют gcc-3.4.

GCC 4.1 собирает весь ПРАВИЛНО НАПИСАННЫЙ софт. Коряво написанный - сто раз подумай, прежде чем его устанавливать. Если софт нормальный, но пару ошибок, выявленных GCC 4 в нём затесалось, -исправляется элементарно.

>Имелась в виду практика прописывания в Requires: всего что надо и не очень.

1) Примеры, плиз.

2) У вас притензии к Requires вообще или к тому, кто их прописал "неправильно"?

Таки прям стахановцы. Лучше бы kudzu в FC5 проверили бы реально на X700 карточке. Или бы реально работали бы с замечаниями тестеров, которые неоднократно предупреждали их о "качестве" кода.

> Они собирают даже wine с sane и поддержкой gphoto. Именно поэтому тот же wine тянет всю эту хрень. Но если ее не поставить, то wine не запустится.

Вот из-за этого мне всё меньше нравится RedHat (пользуюсь им со времен RH 4.2). И то, что RPM не поддерживает зависимостей вида Suggests: и Recommends: ситуацию не улучшает.

> И то, что RPM не поддерживает зависимостей вида Suggests: и Recommends: ситуацию не улучшает.

Сам хоть понял что сказал? Если бинарники wine собраны со ссылками на эти билиотеки - то как ни старайся - он просто НЕ ЗАПУСТИТСЯ без них. Не устраивает? Сделай свою сборку - в spec'ах можно делать ifdef, а rpmbuild понимает параметры для этих ifdef

>> И то, что RPM не поддерживает зависимостей вида Suggests: и Recommends: ситуацию не улучшает.

>Сам хоть понял что сказал?

Вполне

> Если бинарники wine собраны со ссылками на эти билиотеки - то как ни старайся - он просто НЕ ЗАПУСТИТСЯ без них.

Слепить wrapper, работающий через dlopen, совсем не сложно. Но смысла нет из-за негибкости системы зависимостей RPM.

> Не устраивает? Сделай свою сборку - в spec'ах можно делать ifdef, а rpmbuild понимает параметры для этих ifdef

Не устраивает. Делал свои сборки лет 5. Сейчас, правда, собираюсь использовать стандартные (винты нынче большие).

>> Если бинарники wine собраны со ссылками на эти билиотеки - то как ни старайся - он просто НЕ ЗАПУСТИТСЯ без них.

> Слепить wrapper, работающий через dlopen, совсем не сложно.

Или даже weak-символы?

>>Имелась в виду практика прописывания в Requires: всего что надо и не очень.

>1) Примеры, плиз.
Пример приводил выше -- kpdf требует kdebase. Зачем? Он же с ней не линкуется. По опыту использования др. fc-based дистров многие kde'шные пакеты требовали kdebase. Сейчас в федоре такая же ситуация?
>2) У вас притензии к Requires вообще или к тому, кто их прописал "неправильно"?
В большинстве случаев желательно бы никак не прописывать, а положиться на возможности самого rpm. Кроме случаев когда это действительно необходимо. Например *-devel пакет должен требовать основной и т.п.

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

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

> Три безосновательных утверждения в одной фразе - круто!:)))

Сильно поменялись зависимости той же самбы, скажем с версии 3.0.10 до 3.0.22? Или clamav с сендмылом вдруг резко потребовали перехода с .so.N на .so.N+1? Наверное CVS отказывается работать со штатной glibc-2.3.3, и хочет исключительно 2.4, причем специально пропатченую так, что ABI и API оказываются несовместимы?

А если софтина требует такого обновления системных либок, что при этом ломается работа других прог - нафига такое чинить на сервере? ;)

> Сначала ты свёл компы только к серверам, теперь сервера - к "внутренним серверам".

ДМЗ тоже находится "внутри конторы" (но вне внутренней сети), так что "не надо ля-ля" :) Имеются в виду "все серверы", про них изначально шла речь.

> Это к чему вообще приплетено?

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

> Вот как раз из-за подобного бреда я сказал, что ты не представляешь "что такое спеки/ебилды и чем оно отличается от просто сырцов и патчей"

Я сказал что такое спека-ебилда, а не что такое "система пакетного менеджмента, использующая спеки-ебилды". А сравнивать сырцы+патчи с ебилдом - некорректно, ибо одно - исходник, другое - описание процедуры получения бинарников из оных (ну и много чего еще).

> С autotools/scons/etc. перепутал :)

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

> Решил клоуном побыть? Я говорил, что зависимости на библиотеки при сборке пакета выясняются автоматически и в готовый пакет проставляются (при этом в спеке никаких Requires может вобще не быть).

А на кой черт тогда в спеках из .srpm от SuSE имеются офигенно длинные строчки "requires" c ветвлениями "if" кое где, если все это (или большая часть) высчитывается автоматически... э?

> Угу. "Только одной машины" - это у тебя. С таким подходом тебе больше и "не светит". "С разным набором сервисов" и под разные задачи - не асилил? Объясняю: сервера - они вообще-то разные бывают, для разных задач и т.п.

Где-то слышал о том, что сервера не только шум производят ;) Запускать только нужные демоны из набора имеющихся сэр не обучен? *)

> :)))))))) Просто нет слов:) Пошли уже аргументы: "медленно выполненная работа лучше, чем быстро выполненная". "- За сколько сделаешь? - Ну, за день.... - А за неделю сможешь? - Ну, тут без помошника не обойтись..." (с) "Граф Калиостро":)))

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

> Клонируй-клонируй... Если у тебя все (все один?) компы выполняют одно и то же...

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

Или зачем например народ из саппорта пишет телеги на тему "стандартный софт для такой-то такой-то должности" и делают по ним готовые имиджи? Тоже ленятся небось колбасить винды и офисы со всякими "студиями" с нуля? ;) Или рекомендовать им давать на каждое рыло права локального админа, чтобы юзеры ставили сами любой варез и вирусы?

> "Минусы" - в студию!

Извиняюсь, оговорился - "автоматического отслеживания зависимостей в системах на базе rpm" - минусы как были, так и остались - негибкость (см. выше про required-recommended-optional), невозможность обойтись без вытягивания зависимостей при, например, линковке к .so.N+1, но полном сохранении совместимости с оной либкой по API/ABI.

Портеджи гораздо гибче, и к ним соответственно претензий меньше.

> Хочется дом на Рублевке и что? ;)

Мы над этим работаем :)

>> Хочется дом на Рублевке и что? ;)

>Мы над этим работаем :)

мне тоже поработайте, плз.

>в чем принципиальное отличие спеков-ебилдов от слакбилдов, к примеру?

Зависимости

>на кой черт тогда в спеках из .srpm от SuSE имеются офигенно длинные строчки "requires" c ветвлениями "if" кое где, если все это (или большая часть) высчитывается автоматически... э?

Если ты не перепутал Requires и BuildRequires, то это вопрос не ко мне, а к SuSE. Про SuSE я даже спорить не стану, потому как о ней знаю очень мало.

>Не передергивай

>авралы с серваками есть вещь ненужная.

Это ка краз ты передёргиваешь:) Авралы - они в обслуживании бывают, а не при инсталляции.

>Смысл с нуля ставить каждую ноду кластера

Кластер - как раз одна сущность в виполнении работы, так что ноды в нём - по определению практически одинаковые.

> но для другого подразделения, если можно поправить пару десятков строк в конфигах?

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

>Или зачем например народ из саппорта пишет телеги на тему "стандартный софт для такой-то такой-то должности" и делают по ним готовые имиджи?

У вас в конторе только одна должность? вы всем "клонируете" "стандартный софт для такой-то такой-то должности"?

>Или рекомендовать им давать на каждое рыло права локального админа, чтобы юзеры ставили сами любой варез и вирусы?

Это ты сам придумал.

>минусы как были, так и остались - негибкость (см. выше про required-recommended-optional)

"Выше про негибкость зависимостей в rpm" - это я эту тему начал:)

>невозможность обойтись без вытягивания зависимостей при, например, линковке к .so.N+1, но полном сохранении совместимости с оной либкой по API/ABI.

Изменение с .so.N на .so.N+1 без изменения API/ABI - за такое расстреливать на месте нужно (таким любят "баловаться" в либах гномеры) - не нужно выдавать баги и кривости за недостатки системы зависимостей, при том, что мэйнтейнеры зачастую такие "баловства" мэйнстирима патчат и в пакете лежат уже либы без лишнего N+1.

>Портеджи гораздо гибче, и к ним соответственно претензий меньше.

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

> Как показывают новые компы Apple - существенна. > В service pack два изменили firewall и исправили баги. Все. > Точно так же можем на rh 9 поставить свежие iptables и обновить багфикс. > Или может sp2 стал лучше поддерживать процессоры, у него улучшилось smp, появилась поддержка хардварного переключения между операционками? > Даже directx застыл - лишь добавляются dll-ки по месяцам (апрель, май и т.п.) > Смотрим на windows 2003 сервер. Рыдаем.

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

> Дураки. Поэтому появился xorg, который за два года сделал больше, чем консорциум за много лет.

И тем не менее, в .srpm для xorg-6.9.0 то немереное количество патчей сохранилось... ну или в гентушном наборе патчей.

> Вы не любите китайцев и у вас не было трех-четырех язычных систем? А в курсе, что винды полностью внутри юникодные? И уж open office жрет ровно столько же, сколько и нативный, только работает быстрее.

Я действительно не люблю китайцев... (вот если бы делали исключительно для японцев - то понял бы %) ) Зачем из-за извращенных алфавитов восточных людей, коим нужен utf-32, втыкать полную поддержку оного в каждый кусочек стандартной версии дистрибутива, когда абсолютному большинству достаточно нормальной 8-битки? Требования рынка? В Азии все равно клепают отдельный дистр для себя. В России - достаточно двухязычной (koi8-r + iso-8859-1), в любой европейской или латиноязычной стране - по аналогии.

Какие винды внутри юникодные - видно по именованию кириллицей на файловой системе. GTK тогда еще более юникодовый и правильный, откуда глюком море и вылазит. UNICODE-ready - дело хорошее, но втыкать его везде и делать по умолчанию - нафик-нафик.

Сэр Джекилл, у вас же вроде у самого везде воткнута koi8-r?

> Да. Это одна из целей этого дистриба. Кстати, хочу заметить, что gentoo пользуется наработками fc, как и debian. И обратный процесс тоже наблюдается.

Так то естественное явление для OSS-коммьюнити.

> А что, какие-то проблемы с тем, что дистриб, на основе которого потом делаются промышленные решения, раздается бесплатно, со всеми технологиями? Или может gentoo что-то гарантирует? > Или может быть microsoft предоставляет какие-то космические гарантии?

Вообще не предоставляют и ответственности не несут, а вот SUN относится гораздо серьезнее, HP - аналогично. Пусть они берут больше денег, но качество поддержки того стоит.

> Зависимости

Ну вот и договорились :)

> Если ты не перепутал Requires и BuildRequires, то это вопрос не ко мне, а к SuSE. Про SuSE я даже спорить не стану, потому как о ней знаю очень мало.

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

> Это ка краз ты передёргиваешь:) Авралы - они в обслуживании бывают, а не при инсталляции.

Разве что место кончится, или резервные генераторы не потянут отключение электроэнергии на всю контору... ну или провалимся в АД на перегруппировку вследствие землятрясения :)

Я потому и сказал, что лучше пошевелить головой и руками до и в процессе установки, чем отлаживать все на ходу :)

> Кластер - как раз одна сущность в виполнении работы, так что ноды в нём - по определению практически одинаковые.

А cvs/svn, апач, мускуль, самба, пхп и т.д. - не одна по сути сущность в первичной настройке? С ораклом та же самся фигня - много шуршания мозгой при проектировании, мало при эксплуатации.

> Т.е. твой прицип: ставлю всё, что может понадобится в конторе, а потом разруливаю специфику конфигами?

Не "в конторе", а в "подразделении конторы", не будем впадать в крайности...

Как предпочтительный вариант. Бакапить /etc /home и /var, или бакапить / полностью? В той же федоре было примерно так же с вариантами инсталляции "сервер", "рабочая станция", etc. В нынешнее время объем системы в сравнении с объемом данных коими система шевелит - ничтожный мизер, в особенности если требуется множество машин, но бакапить однотипный софт - та ну его.

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

> У вас в конторе только одна должность? вы всем "клонируете" "стандартный софт для такой-то такой-то должности"?

Не "мы", а тем кому по должности положено - сначала должны смотреть кому ставить, потом клонировать, потом минимальные шевеления по настройке, ибо один фиг Active Directory шуршит. Если нужен специфичный софт - то доставляется в индивидуальном порядке. Вообще - это вопрос отлаженности техпроцесса на предприятии...

Зачем, например, секретарше или манагеру терминальный клиент, или там visual studio + oracle forms? Точно так же, зачем девелоперам цыгвин и зоопарк интерпретируемых языков...

> Это ты сам придумал.

Мне такое в кошмарных снах даже не снится :))

> "Выше про негибкость зависимостей в rpm" - это я эту тему начал:)

Зато я в промежутке между ее прочтением и написанием ответа - успел два раза поспать :)

> Изменение с .so.N на .so.N+1 без изменения API/ABI - за такое расстреливать на месте нужно (таким любят "баловаться" в либах гномеры) - не нужно выдавать баги и кривости за недостатки системы зависимостей, при том, что мэйнтейнеры зачастую такие "баловства" мэйнстирима патчат и в пакете лежат уже либы без лишнего N+1.

Классика - libexpat.so.1 && libexpat.so.0 + дрова от ATI с их утилкой fglrxconfig. АБИ - не изменилось нифига, симлинком лечится только если юзеру в . и запуск с LD_LIBRARY_PATH=.

А при сборке из сорцов - разницы вообще нет, вся линковка идет уже на .so.1.

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

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

В идеале за source-based будущее, т.к. мощь процов и ПСП памяти растет, а объем кода не особо меняется, плюс нет гимора с совместимостью по бинарям. Пара-тройка лет максимум и зоопарку rpm придет йок.

> мне тоже поработайте, плз.

В гости пригласим %)

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

rpm2tgz несомненно, благо начинка у rpm однотипная.

> И тестирование у FC уже есть. Оно спускается с предыдущих версий, с коммерческих релизов и т.п. У слаки оно тоже по идее должно спускаться с предыдущих версий. Насчет коммерческих релизов не уверен.

В слаке тестирование - это фактически current + прислаемые Патрику слакобилды от сторонних разработчиков, которые включаются в состав при должном основании. ИМХО слака сама по себе в силу отсутствия погони за модными примочками весьма прилично отлажена и стабильна.

> Это ты сейчас так говоришь. Будет другая задача - будет у тебя xen.

Вот тогда и почешемся на тему внедрения... Чесслово, не могу представить зачем он нужен здесь, даже в будущем... специфика конторы однако. Разве что работу сменить :)

> Значит на сервере тебе иксы не нужны. Там, где они нужны, можешь логиниться не в гном. Гном без hal тоже работает, но не все компоненты. А если не работают все компоненты - по кой черт выдирать его оттуда?

Не могу однозначно ответить. Если рассмотреть конкретный пакет и его зависимости, наверное можно примерно определить его "нужность" на сервере...

Как-то я дома озадачился на тему "а что, если минимизировать требования к месту и времени сборки"... И на примере того же PHP - если брать по максимуму, то в зависимости попадут и иксовые либы, и вообще цельный оракл можно присобачить при желании :)

Поддержка intel Mac -- это хорошо, нужно попробовать..

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

Ставь. Если нет compat, то с nodeps. И исключи его в yum на обновлении.

И все.

>В идеале за source-based будущее, т.к. мощь процов и ПСП памяти растет, а объем кода не особо меняется, плюс нет гимора с совместимостью по бинарям. Пара-тройка лет максимум и зоопарку rpm придет йок.

Ты забываешь, что и объем кода растет. mandrake 7.x вмещался на 1 компакт-диск со всей хренью и kde/gnome впридачу (у меня есть диск, сам когда-то с него ставился).

А теперь мы сидим на 3.5 дисках + rescue и скоро нам понадобится больше.

(Я не беру коммерческие дистры - тот же suse 8, что ли, 7 дисков был).

>И тем не менее, в .srpm для xorg-6.9.0 то немереное количество патчей сохранилось... ну или в гентушном наборе патчей.

Да и в 7.0 порядком, хотя я видел, что часть ушло.

>В России - достаточно двухязычной (koi8-r + iso-8859-1), в любой европейской или латиноязычной стране - по аналогии.

Ну французский и немецкий несколько отличается от iso-8859-1.

А что касается китайского - у нас в стране достаточно уже людей, которые торгуют с Китаем.

>Сэр Джекилл, у вас же вроде у самого везде воткнута koi8-r?

Ага. Но тот же уникодный внутри KDE (и его консоли) позволяют мне из документа одной локали переносить данный в документ с другой локалью.

И это удобно. Еще McMCC писал полгода назад, что имея юникодные внутри и снаружи программы пофигу какая у тебя локаль.

Кстати, держу я ее исключительно из-за xmms и mc.

>Вообще не предоставляют и ответственности не несут, а вот SUN относится гораздо серьезнее, HP - аналогично.

Стоп. У HP вообще аналога Fedora нет. У Sun есть Open Solaris - это как раз та же Fedora. Никто ответственности не несет.

А вот RHAS, RHES - другая тема.

>Сильно поменялись зависимости той же самбы, скажем с версии 3.0.10 до 3.0.22? Или clamav с сендмылом вдруг резко потребовали перехода с .so.N на .so.N+1? Наверное CVS отказывается работать со штатной glibc-2.3.3, и хочет исключительно 2.4, причем специально пропатченую так, что ABI и API оказываются несовместимы?

Мне хочется поинтересоваться, ты читаешь changelog'и на те же glibc? Собрать всю эту хрень можно практически с чем угодно. Но собирая новые glibc часто бывает нужно пересобрать и часть софта.

У тебя стабильность должна повыситься. Так в чем проблема?

>А на кой черт тогда в спеках из .srpm от SuSE имеются офигенно длинные строчки "requires" c ветвлениями "if" кое где, если все это (или большая часть) высчитывается автоматически... э?

А это потому, что ты можешь собрать rpm-пакет без чего-либо.

>Одна команда занимается поддержкой одного, другая - другого... Сэр не работал в крупных конторах? ;) Смысл с нуля ставить каждую ноду кластера или там сервер с одинаковой функциональностью, но для другого подразделения, если можно поправить пару десятков строк в конфигах?

Еще скажи, что в крупных конторах ставят slackware. И названия контор.

>Извиняюсь, оговорился - "автоматического отслеживания зависимостей в системах на базе rpm" - минусы как были, так и остались - негибкость (см. выше про required-recommended-optional), невозможность обойтись без вытягивания зависимостей при, например, линковке к .so.N+1, но полном сохранении совместимости с оной либкой по API/ABI.

Ну лучшие зависимости, наверное, в debian.

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

Ты вспомни свои любимые винды - там процентов 50-60 не используется, но при подключении все взлетает. Тут мы имеем возможность поставить что-то и при подключении любой хрени это что-то взлетит.

>Пример приводил выше -- kpdf требует kdebase. Зачем?

Я не удивлен. А нафига нужен KDE-шный софт без KDE? Без его тем? И т.п.

Нет, есть дрочилы (только так я их могу назвать), которые сидят в WM и используют konqueror, kmail и прочее, наивно полагая, что они экономят ресурсы, память и очень удобно работают...

>Сам хоть понял что сказал? Если бинарники wine собраны со ссылками на эти билиотеки - то как ни старайся - он просто НЕ ЗАПУСТИТСЯ без них.

Именно. Так что suggested - это для плагинов или еще чего.

>Таки прям стахановцы. Лучше бы kudzu в FC5 проверили бы реально на X700 карточке. Или бы реально работали бы с замечаниями тестеров, которые неоднократно предупреждали их о "качестве" кода.

X800 работает.

Ну а kudzu будут отрывать.

>Почему "меняя"? почему "под себя"?:) Чаще "устанавливая" и "не для себя только".

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

>Попадалось, уж поверь:)

Не поверю, пока не увижу названия. Я что, верующий, что ли?

> Я не удивлен. А нафига нужен KDE-шный софт без KDE? Без его тем? И т.п.
И поэтому пакеты нужно собирать через жопу? kpdf только как пример приведён, это общая для дистра манера сборки.

>Потому что либо ты стандартные вещи ставишь, либо меняешь под себя (свою контору).

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

>Не поверю, пока не увижу названия.

Может, не самый удачный пример, но всё же:

Есть пакет с софтиной и несколько пакетов с GUI-темами для неё. Сама софтина без темы не работает, ей нужна хотя бы одна из тем (любая).

> Ты забываешь, что и объем кода растет. mandrake 7.x вмещался на 1 компакт-диск со всей хренью и kde/gnome впридачу (у меня есть диск, сам когда-то с него ставился).

Та не очень сильно растет на самом деле, а уж судить по увеличению объема дистрибутива - на то воля мэйнтейнеров, та же слака два года как занимает 2 СД... не могу сказать точно, что было раньше - нет .iso, но думаю примерно столько же со времен 9.х.

По размеру бинарников - приличный рост есть между major-релизами, типа опенофиса, КДЕ и т.д. - а внутри прирост в процентах...

>А теперь мы сидим на 3.5 дисках + rescue и скоро нам понадобится больше. >(Я не беру коммерческие дистры - тот же suse 8, что ли, 7 дисков был).

Все зависит от дистрибутива, гентушники вообще могут сидеть на live-cd или флешке, лишь бы оно позволяло загрузиться и начать лить файло с нета :)

> Стоп. У HP вообще аналога Fedora нет. У Sun есть Open Solaris - это как раз та же Fedora. Никто ответственности не несет. > А вот RHAS, RHES - другая тема.

Сорри, тут я больше про железо, а потом уже ОС. Но, да - сравнивать стоит опенсолярку и федору, или уже RHAS/ES и Solaris... И в последних двух случаях качество продукта (только серверные оси...) и сервис от SUN/RH выглядит куда предпочтительнее MS-овского, и тем более если рассматривать и железные вопросы тоже.

> Мне хочется поинтересоваться, ты читаешь changelog'и на те же glibc? Собрать всю эту хрень можно практически с чем угодно. Но собирая новые glibc часто бывает нужно пересобрать и часть софта.

Читаю разумеется. И если написано, что АПИ не поломалось - то все поверх соберется так же чисто, или даже не потребуется пересборки (с 2.3.2 - именно так, причем даже при переходе на NTPL несовместимостей оказался минимум). А если же как с 2.4 glibc'ей - так там русским языком написано, что "девелопмент" и на продакшнах мейнтейнеры велят юзать 2.3 ветку, что и делается.

> У тебя стабильность должна повыситься. Так в чем проблема?

Повышается, проблем никаких, ежели не торопиться втыкать свежак.

> Еще скажи, что в крупных конторах ставят slackware. И названия контор.

На рабочие машинки - RedHat, благо это дело сертифицировано железным вендором и во избежанье гимора изначально включено в контракт...

> Ну лучшие зависимости, наверное, в debian.

Не могу ничего сказать, "ниасилил" установку Sarge :)

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

"Минус рассмотренный под другим углом запросто может оказаться плюсом" :)

> Ты вспомни свои любимые винды - там процентов 50-60 не используется, но при подключении все взлетает. Тут мы имеем возможность поставить что-то и при подключении любой хрени это что-то взлетит.

Винды мои любимые? 8[ ] Увольте... в чем работать - пофиг, но для души - только линукс :) А в своем собственном - при ребуте запускается только то, без чего никак и никуда, остальное по надобности...

> > Если бинарники wine собраны со ссылками на эти билиотеки - то как ни старайся - он просто НЕ ЗАПУСТИТСЯ без них.

> Слепить wrapper, работающий через dlopen, совсем не сложно. Но смысла нет из-за негибкости системы зависимостей RPM.

У нас на улице дождь и в лужах от него пузыри - не вы ли в этом поучаствовали?

1. враппер далеко не всегда применим. Особенно если код реализован всякими ifdef/ifndef

2. Если такой враппер есть, RPM вполне рпозволяет вам организовать цепочку software->[requires]->wrapper, и тогда бакэнды совсем не от чего не зависят. В чем проблема-то?