Ciaran McCreesh подобно ответил на вопросы (http://lab.obsethryl.eu/content/paludis-gentoo-and-ciaran-mc...) касающиеся проекта Paludis (http://paludis.pioto.org/), разработанной в качестве альтернативы системе Portage, для Gentoo Linux. Вначале Paludus представлял собой программу для разрешения проблем с зависимостями в Portage, но затем превратился в отдельный пакетный менеджер. Создать новую систему оказалось проще, чем исправлять ошибки и наращивать функциональность Portage, который представляет собой запутанную смесь кода (http://paludis.pioto.org/faq/general.html), не отталкивающуюся от единого дизайна.URL: http://lab.obsethryl.eu/content/paludis-gentoo-and-ciaran-mc...
Новость: https://www.opennet.ru/opennews/art.shtml?num=13293
Иммм... интересно, а что скажут сами пользователи Gentoo, кто использовал эту систему, правда ли что с portage так всё плохо, как выразился человек написавший Paludis???:-\
пользователи скажут, шо вобщем-то все ок с портеджом...Но с точки зрения разработки для портеджа - может быть все и наоборот...
Человек, написавший Paludis, имхо довольно спорный товарищ.
Насколько я помню, именно после конфликта с ним от Gentoo отвалил DRobbins.
Сам сижу под Gentoo. Никаких проблем с Portage не заметил. Я что-то не так делаю? :)
Вот и у меня все ок
На уровне пользователя портаж действительно очень удобная и стабильная система. На уровне разработки видимо есть проблемы. Имхо палудус или портаж разница не велика, главное что бы это было удобно и функционально.
+1 ко всем постам. когда перыый раз поюзал portage облизнулся и пересел на генту с суси ))
да....когда фантазия уже превышать возможности пакетного дистра - то Генту просто монополист ;)
непонятно как могла "запутанная смесь кода" оказаться в генте? :-[ ]
Господа!
Боюсь конечно развести холиварчик. Но, если бы вы работали с портами FreeBSD, вы бы поняли что такое "единый дизайн" и причины появления таких альтернатив как Paludis.
И такие "фичи" как emerge depclean и revdep-rebuild, IMHO, я бы расценил как костыль, нежели как фичу...Это только с точки зрения пользователя, - не имеющего подобной альтернативы ни в одном другом дистрибутиве Linux, - портежи безупречны...
> вы бы поняли что такое "единый дизайн"Ну единый, а толку-то. У портов тоже проблемы есть.
>Господа!
>Боюсь конечно развести холиварчик. Но, если бы вы работали с портами FreeBSD,
>вы бы поняли что такое "единый дизайн" и причины появления таких
>альтернатив как Paludis.
>И такие "фичи" как emerge depclean и revdep-rebuild, IMHO, я бы расценил
>как костыль, нежели как фичу...
>
>Это только с точки зрения пользователя, - не имеющего подобной альтернативы ни
>в одном другом дистрибутиве Linux, - портежи безупречны...Ага, фряха вообще не умеет работаь с портами. Попробуйте поставить php4 в префикс /usr/local/php4 а пхп5 в /usr/local/php5 - и скажите через сколько часов получиться.
Да и вообще порты фряхи - архаизм. До сих пор половина того, что надо поставить не просто make install ставиться криво.
cd /usr/ports/lang/php5 && make install clean DESTDIR=/usr/local/php5или
portupgrade -N -m 'DESTDIR=/usr/local/php5' lang/php5
Интересно, много тут людей,которые ставят php4 и php5 вместе? ;)
>Да и вообще порты фряхи - архаизм. До сих пор половина того, что надо поставить не просто make install ставиться криво.Мне кстати интересно, как в генту мне добавить модуль к php (например, mysqli) не пересобирая все остальные? А то сейчас правлю package.use и полный emerge.
А насчОт "криво" - только одну кривизну вижу: старые порты, не понимающие make config. В результате portupgrade неадекватен. :(
Для таких портов /etc/make.conf рулит. :) Я вообще стараюсь туда все описывать.
Что такое нужно изобрести, чтобы не хватало make config, make install и опций WITH_*/WITHOUT_* ? Скорее всего вы сами себе буратино.
... ну так он останется.http://paludis.pioto.org/clients/reconcilio.html
reconcilio - Rebuilds packages with broken linkage.
Descriptionreconcilio searches for and rebuilds packages that are linked against libraries that are not present on the system, or a specific library named by the user.
тот же revdep-rebuild, только печатать уже смешнее.
>тот же revdep-rebuild, только печатать уже смешнее.LOL
а вообще, юез подобной вспомогательной тулзы, кажеться, и не так просто обойтись
в source-based дистре.
Посему, и нервничать тут нечего.
Ну порты FreeBSD, потихоньку учат новому, может быть не столь быстро и не столь инновационно, но у FreeBSD политика в ентом плане, максимальная стабильность, они эволюционируют потихоньку, кому-то слишком медленно, кому-то в самый раз, каждый в итоге может выбрать себе инструмент по вкусу...:)
Совершенно верно, portage слишком жестоко замороченная тормознутая система с множеством костылей и хаков.
Одним из наибольших "костылей" являются слоты, скажу вам как разработчик.
>Одним из наибольших "костылей" являются слоты, скажу вам как разработчик.опа, опа...
товарищь, разработчик, а не подскажете ли нам _ровный_ метод установки разных версий одной софтины, кроме как слотирование?
>>Одним из наибольших "костылей" являются слоты, скажу вам как разработчик.
>
>опа, опа...
>товарищь, разработчик, а не подскажете ли нам _ровный_ метод установки разных версий
>одной софтины, кроме как слотирование?Примеры в студию. Все, что можно постаить - ставится. Все что нельзя - конфликтится. И это правильно. Если сильно надо, ну разведи в разные jails или чруты.
кривая не кривая, но на питоне, а "прямой" paludis сегфолтится будет...
Хотя portage и функциональнее FreeBSD портов
на костыль он знатный, если в portage появляется внутреняя проблема
то разрулить ее практически не реально
>если в portage появляется внутреняя проблема то разрулить ее практически не реальноВерно говоришь: _ЕСЛИ_
вот была у меня "проблема"... Решил я как-то убрать из синка портов проприетарщину и консерватизм: вмварь и бздю.
Благо порты синкаются rsync'ом (а не какой-то специальной узкозаточенной тулзенью),
стандартную команду можно легко найти в мане и переопределить в make.conf, добавив нужное.
Добавил я пару exclude'ов - и вссе отлично заехало без вышеуказанных вещей.
Но, ебилды тоже пишут люди и тоже ошибаются. Наткнулся я на то, что некоторые ебилды без разборов флагов хотят видеть свои патчи на бздю... даже если мир у меня GNU.
Ну, поначалу просто подправил ебилд - думал, это редкость. Но ошибся.
И пришлось лезть в сам портедж. Вот тебе налицо _внутреняя_ проблема: портедж выходит с ругательством что не найден какой-нить там траляля-freebsd.patch... ну, без каментов...Ну и что, беру я и правлю нужный скриптик портеджа чтоб он не вываливалсо, но пусть продолжает ругаться. Делаю патчик для этого дела и вписываю в скрипт обновления команду патчить это дело каждый раз, когда обновляеться пакер портеджа - ВСЕ. Проблема решена не решена, но подкостылена очень простым путем.
Справился бы ты так же просто, если бы пакетный менеджер был бинарный, а не в скриптах, ка к portage?
На фряхе, если что, тоже не бинарный менеджер. Сколько на ней сижу.. ну НЕТУ у меня таких проблем.
если на венде сидеть и в косынку только играть - тоже мало проблем будет.А вот шаг в сторону - уже вопросы начинаются...
>Справился бы ты так же просто, если бы пакетный менеджер был бинарный,
>а не в скриптах, ка к portage?Разумеется. Не вижу проблемы -- хотя бы потому что build идет совсем на других машинах (если вести речь о собственно yum/apt репозитории). Более того как показывает практика большинство пакетов с кастомными флагами на последующих этапах все равно пересобираются с недостающими, потому что "надслойки" (в данном случае скорее подразумевается связь библиотека -- приложение) над этим программным обеспечением требуют полноценной поддержки.
Рассмотрим ситуацию когда у вас 20-цать машин в кластере -- Вы аналогичное шаманство будете производить на каждой машине?
Если Вам пришла идея собрать бинарный пакет в portage и разбросать его по остальным машинам -- то грошь-цена вашей пакетной системе, т.к. по сути она тогда ничем не отличается от binary-based.
>Рассмотрим ситуацию когда у вас 20-цать машин в кластере -- Вы аналогичное
>шаманство будете производить на каждой машине?пардон, но использование портеджа не исключает использование мозга
>Если Вам пришла идея собрать бинарный пакет в portage и разбросать его
>по остальным машинам -- то грошь-цена вашей пакетной системе, т.к. по
>сути она тогда ничем не отличается от binary-based.при разливке собранного софта уже тяжело оптимизировать процесс глубже, чем
заливка на машину->запись на ФС->регистрация в базе пакетного менеджера.Пардон еще раз, но ведь этап сборки уже далеко не столь элементарен.
И красота/скорость, с которой можно переконфигурить систему для сборки по новым условиям,
у портеджа намного больше, чем у любой генерилки спеков.
Будут в системе иксы или нет - решаеться одним словом в конфиге.Портедж, также, способен собрать софтину и проставить ее в систему, минуя этап создания
пакета (тебе же приходиться всегда делать RPMку и лишь потом ставить ее, что не всегда удобно и нужно). И если же понадобиться когда-нибудь взять сию софтину и сделать из нее пакет для установки - нет проблем: одна команда и разливай софтину куда нужно. И все это одной командой (quickpkg <portname>). Можно, также, и просто собрать пакет без установки в систему (просто одно слово в конфиге или комм. строке).
Вот в чем сила портеджа, доселе не превзойденная ничем.
>>Рассмотрим ситуацию когда у вас 20-цать машин в кластере -- Вы аналогичное
>>шаманство будете производить на каждой машине?
>
>пардон, но использование портеджа не исключает использование мозгаИз чего делаем заключение -- что красивого способа не существует. И каждый "дроч*" так как хочет.
>>Если Вам пришла идея собрать бинарный пакет в portage и разбросать его
>>по остальным машинам -- то грошь-цена вашей пакетной системе, т.к. по
>>сути она тогда ничем не отличается от binary-based.
>
>при разливке собранного софта уже тяжело оптимизировать процесс глубже, чем
>заливка на машину->запись на ФС->регистрация в базе пакетного менеджера.очевидно что portage в том понимании, которое всегда преподносят как манну небесную его поклонники, маштабируется только на одну машину. Далее по сути -- идеология binary based.
>Пардон еще раз, но ведь этап сборки уже далеко не столь элементарен.
>И красота/скорость, с которой можно переконфигурить систему для сборки по новым условиям,
>
>у портеджа намного больше, чем у любой генерилки спеков.
>Будут в системе иксы или нет - решаеться одним словом в конфиге.Если быть совсем честным -- это далеко не заслуга portage, а заслуга его прародителя -- ports.
ИМХО, если уж козырять действительно преимуществами portage -- то нужно указывать его достоинства. Одно из них было упомянуто -- slots, однако оно тоже не лишино недостатков. Кстати, спорный момент действительно ли это их заслуга или же pkgsrc (вроде хронологически их draft появился чуть раньше).
> И если же понадобиться когда-нибудь взять сию софтину и сделать из нее пакет для установки - нет проблем: одна команда и разливай софтину куда нужно. И все это одной командой (quickpkg <portname>). Можно, также, и просто собрать пакет без установки в систему (просто одно слово в конфиге или комм. строке).Из этого можно сделать вывод, что portage -- лишь удобное средсто для сборки *бинарных* пакетов.
Что же получили в итоге:
1. следуя изначальной идеологии portage -- source-based -- годится только для небольшого кол-ва хостов.
2. по сути portage ни более ни менее чем альтернативное срество для сборки !бинарных! пакетов.
>Если быть совсем честным -- это далеко не заслуга portage, а заслуга
>его прародителя -- ports.я сравнивал портедж с binary-based дистром. Какая разница откуда пошли идеи портов?
Почему тогда ты не вспоминаешь откуда взялся yum, например?
>ИМХО, если уж козырять действительно преимуществами portage -- то нужно указывать его
>достоинства.козыряю преимуществами не перед историей и изобритениями, а перед binary-based дистрами. Ну приведи свой пример с бздей с портами - там и посмотрим у кого длиннее. Чего лезть в чужое обсуждение с оффтопиком?
>Из этого можно сделать вывод, что portage -- лишь удобное средсто для
>сборки *бинарных* пакетов.ыыы
Дык ничего друго я и не сказал :)
В конечном счете, мы, вообще-то, тут обсуждаем сборку софта для _компов_, которые с бинарями работают (если ты не знал %).
За сим и направленность на сборку софта - очевидна :)
Молодец, что так быстро заметил :D
>Что же получили в итоге:
>1. следуя изначальной идеологии portage -- source-based -- годится только для небольшого
>кол-ва хостов.Оно годиться для удобной сборки. А scp/rsync/wget никто не запрещал, и это, как было сказано выше, чрезвычайно более простая задача, нежели конфигурирование для сборки.
>2. по сути portage ни более ни менее чем альтернативное срество для
>сборки !бинарных! пакетов.:D
ну, заработал второй плюс!
Заметил!! Ура!
Полагаю, Вы сами на все оставшиеся вопросы найдете ответы и достойного собеседника для их абсуждения.>[оверквотинг удален]
>Оно годиться для удобной сборки. А scp/rsync/wget никто не запрещал, и это,
>как было сказано выше, чрезвычайно более простая задача, нежели конфигурирование для
>сборки.
>
>>2. по сути portage ни более ни менее чем альтернативное срество для
>>сборки !бинарных! пакетов.
>
>:D
>ну, заработал второй плюс!
>Заметил!! Ура!
>Полагаю, Вы сами на все оставшиеся вопросы найдете ответы и достойного собеседника
>для их абсуждения.не дуйся :)
просто портедж действительно просто удобная собиралка системы,
ну а заодно и пакет менеджер.
>>Рассмотрим ситуацию когда у вас 20-цать машин в кластере -- Вы аналогичное
>>шаманство будете производить на каждой машине?
>пардон, но использование портеджа не исключает использование мозгаАдминистрирование кластера его _требует_. Возможно, потому гентушников туда и не пускают...
>>Если Вам пришла идея собрать бинарный пакет в portage и разбросать его
>>по остальным машинам -- то грошь-цена вашей пакетной системе, т.к. по
>>сути она тогда ничем не отличается от binary-based.Дык оне ж про localhost. Ну или прочие два тазика, когда "тут играем, тут не играем, тут селёдку заворачивали" по каждому более-менее постоянно в голове варится и за год не забывается.
Я вот уже и не помню, что где как -- выяснение состояния начинается обычно с rpm -qa | sort | less и rpm -Va | grep ^/etc, когда пора перебраться на другой бранч, например.
>Пардон еще раз, но ведь этап сборки уже далеко не столь элементарен.
Можете не рассказывать, некоторые это и так знают.
>И красота/скорость, с которой можно переконфигурить систему для сборки по новым условиям,
>у портеджа намного больше, чем у любой генерилки спеков.
>Будут в системе иксы или нет - решаеться одним словом в конфиге."А вот блохи"...
Раз уж про блох, то гляньте http://sisyphus.ru/srpm/mplayer/spec, что ли.
>Портедж, также, способен собрать софтину и проставить ее в систему, минуя этап
>создания пакетаИ потом оказаться у разбитого корыта, если это потребуется воспроизвести? Спасибо, плавали, знаем. Когда что-то "по-быстрому" собиралось сбоку и подсовывался бинарник.
>(тебе же приходиться всегда делать RPMку и лишь потом ставить ее,
>что не всегда удобно и нужно).Для тяп-ляп-админа -- разумеется. Ленивые, умные или уже задумывавшиеся над смыслом жизни или пишут статьи вроде http://www.linux.kiev.ua/ru/docs/articles/ideal-sysadm-rpm/, или хотя бы читают их (RPM -- как пример, думать стоит в данном разе о технологии и подходе).
>И если же понадобиться когда-нибудь взять сию софтину и сделать из нее пакет
>для установки - нет проблем: одна команда и разливай софтину куда нужно.Ага, а если в этом куде нужно что-то из нужного собрано не так, как там, где такой пакет собирался? Вариативность-то в гентоо скорее провоцируется, увы. (буду рад ошибиться -- то, что там вариативность по крайней мере относительно управляемая, и так понятно, но проблема не в инструментах, а в людях)
>Вот в чем сила портеджа, доселе не превзойденная ничем.
Ой, тошнит уже от этих песен про неуловимого Джо.
Если бы сегодня (и вчера) на стенде были вот ещё такие вот гентушнички и мож пара слакваристов, ох было бы куда носом ткнуть. А так те же слакваристы только в Бирмингеме пока по-крупному встряли. Видимо, потому что стенда не было, сразу козла в огород пустили...
>Администрирование кластера его _требует_. Возможно, потому гентушников туда и не пускают...Видать, сей фейс-контроль со мной ошибся и не увидел проблем меня пропустить ;)
>>Портедж, также, способен собрать софтину и проставить ее в систему, минуя этап
>>создания пакета
>И потом оказаться у разбитого корыта, если это потребуется воспроизвести? Спасибо,
>плавали, знаем. Когда что-то "по-быстрому" собиралось сбоку и подсовывался бинарник.видать, вы не вкурсе о чем я.
Я говорил о чесной сборке на одной системе, создании пакета и установке на другую систему.
При всем этом все флаги, зависимости и информация о сборке сохраняется.
Так что, слегка незачет по "собиралось сбоку и подсовывался бинарник".
>Для тяп-ляп-админа -- разумеется. Ленивые, умные или уже задумывавшиеся над смыслом
>жизни или пишут статьи вроде http://www.linux.kiev.ua/ru/docs/articles/ideal-sysadm-rpm/, или хотя бы читают их
>(RPM -- как пример, думать стоит в данном разе о технологии
>и подходе).вы меня пытаетесь уговорить, что пакетный менеджер - это важно?
Непонятно зачем терять время... Я сам кого угодно уговорю.
>Ага, а если в этом куде нужно что-то из нужного собрано не
>так, как там, где такой пакет собирался? Вариативность-то в гентоо
>скорее провоцируется, увы. (буду рад ошибиться -- то, что там вариативность
>по крайней мере относительно управляемая, и так понятно, но проблема не
>в инструментах, а в людях)если что-то собрано не так - то добавляем еще один флаг к emerge и выдим
эти пакеты (с необычными флагами сборки) - ну и, следовательно, легко их заменяем,
если нужно.
>Ой, тошнит уже от этих песен про неуловимого Джо.Дык, факты в студию :)
Всегда рад поспорить об этом ;)
>Если бы сегодня (и вчера) на стенде были вот ещё такие вот
>гентушнички и мож пара слакваристов, ох было бы куда носом ткнуть.
> А так те же слакваристы только в Бирмингеме пока по-крупному
>встряли. Видимо, потому что стенда не было, сразу козла в
>огород пустили...Слакварь то зачем сюда?
Я о ней ни слова не сказал. Давайте не будем ;)Ну а по поводу уловимости неуловимых Джо-портов - плз, слушаю в чем же их
большая проблема :)PS До этого Вы выражались более чем сдержанно, когда речь не касалась Вашей работы ;)
Но когда коснулось сборок и пакетов - Ваш тон намного съехал в ЛОР сторону ;)))
Ну да ничего. Это называеться эмоции :) и делает нас людьми. Я лично страдаю этим
намного сильнее ;)
>>Администрирование кластера его _требует_.
>>Возможно, потому гентушников туда и не пускают...
>Видать, сей фейс-контроль со мной ошибся и не увидел проблем меня пропустить
>;)HPC или HA? ;)
>>Спасибо, плавали, знаем. Когда что-то "по-быстрому" собиралось сбоку и
>>подсовывался бинарник.
>видать, вы не вкурсе о чем я.Скорее наоборот.
>При всем этом все флаги, зависимости и информация о сборке сохраняется.
>Так что, слегка незачет по "собиралось сбоку и подсовывался бинарник".Я говорил о том, как поставить мину на системе с пакетным менеджером себе самому. В том разе это был RPM, хотя опять-таки неважно.
Что происходит, если флаги разные (и что-либо из них прямо или косвенно трогает того, с чем ну пусть линковаться заданному честно собранному в пакет бинарнику на целевой системе)?
>вы меня пытаетесь уговорить, что пакетный менеджер - это важно?
Зачем? Я говорю, что для более чем одной машинки, которая живёт не с прошивки -- это по факту важно. Хотите -- верьте, хотите -- нет.
>>Ага, а если в этом куде нужно что-то из нужного собрано не
>>так, как там, где такой пакет собирался? Вариативность-то в гентоо
>>скорее провоцируется, увы. (буду рад ошибиться -- то, что там вариативность
>>по крайней мере относительно управляемая, и так понятно, но проблема не
>>в инструментах, а в людях)
>если что-то собрано не так - то добавляем еще один флаг к
>emerge и выдим эти пакеты (с необычными флагами сборки) - ну и,
>следовательно, легко их заменяем, если нужно.Нанести на голову, смыть, повторить... а если в одном месте with gtk, в другом -- without? или разные libdb4? или ещё какая-нибудь гадость из тех, о которых, похоже, просто не принято задумываться нигде, кроме как у нас?
>>Ой, тошнит уже от этих песен про неуловимого Джо.
>Дык, факты в студию :) Всегда рад поспорить об этом ;)Факт: я считаю, что порты/портеджи -- неуловимый джо.
>PS До этого Вы выражались более чем сдержанно, когда речь не касалась
>Вашей работы ;)Пф. Не припомню, когда она её вообще касалась :)
>Но когда коснулось сборок и пакетов - Ваш тон намного съехал в
>ЛОР сторону ;)))Может быть, но это не было задумано. Собственно, смысл был не подколоть или там опустить, а дать лишний повод задуматься.
>HPC или HA? ;)ping localhost %)))
>Что происходит, если флаги разные (и что-либо из них прямо или косвенно
>трогает того, с чем ну пусть линковаться заданному честно собранному в
>пакет бинарнику на целевой системе)?допустим, на сборочной системе изменился один флаг, из-за которого уже меняется
несколько пакетов (пересобираются с новыми флагами), и собирается еще какая-то софтина.
Все эти пересобранные и собранные заново пакеты ложатся (автоматом) в репозиторий,
и на production системах дается команда установить этот новый пакет с рекурсивной проверкой зависимостей и флагов сборки.
В результате, все тот же набор пакетов переустанавливается из общего репозитория,
заливая новособранные пакеты на production сервера.Жду других примеров if any ;)
>Нанести на голову, смыть, повторить... а если в одном месте with gtk,
>в другом -- without?все кастомные предпочтения каждого пакета лежат в нескольких файлах
под /etc/portage/. Держать эту диру в синке - не составляет технических проблем.>или разные libdb4?
слоты придут на помощь
>или ещё
>какая-нибудь гадость из тех, о которых, похоже, просто не принято задумываться
>нигде, кроме как у нас?а вот гадость - это и есть работа для разработчика ;)
Ну а бояться случайностей - и в админы не ходить.
>Факт: я считаю, что порты/портеджи -- неуловимый джо.принимается :) как мнение
>Пф. Не припомню, когда она её вообще касалась :)а, ну может показалось ;)
>Может быть, но это не было задумано. Собственно, смысл был не
>подколоть или там опустить, а дать лишний повод задуматься.о
именно за этим я и качаю траффик с/на опеннет ;)
>>HPC или HA? ;)
>ping localhost %)))Эх.
>В результате, все тот же набор пакетов переустанавливается из общего репозитория,
>заливая новособранные пакеты на production сервера.Это подразумевает то, что всё потенциально вариативное установлено из пакетов, что ли?
>>Нанести на голову, смыть, повторить... а если в одном месте with gtk,
>>в другом -- without?
>все кастомные предпочтения каждого пакета лежат в нескольких файлах
>под /etc/portage/. Держать эту диру в синке - не составляет технических проблем.Так. Вы, кажется, не представили.
Пример: у разных наших клиентов рабочие места бывают разбросаны по стране. Причём иногда туда есть VPN, а у некоторых его вроде как и не надо и там может быть односторонний доступ. В принципе можно организовать "держание в синке", но куда лучше оказывается не создавать себе подобных проблем вообще.
Разворачиваться они могут в разное время и разными людьми, при этом минимум в одном проекте, в принципе, некоторая вариантивность могла обеспечиваться тем, что группа, находящаяся в командировке по цепочке городов, могла какие-нить замеченные уже после сдачи мелочи править каким-то своим образом, не уведомляя коллег.
Так вот если базовая система провоцирует вариативность, то обеспечить предсказуемый состав систем попросту сложнее.
Не нужна никому на практике эта хвалёная гибкость там, где должно работать. Вот и всё.
>>или разные libdb4?
>слоты придут на помощьА они к пакетам, локальной сборке или куда угодно?
>>или ещё какая-нибудь гадость из тех, о которых, похоже, просто
>>не принято задумываться нигде, кроме как у нас?
>а вот гадость - это и есть работа для разработчика ;)
>Ну а бояться случайностей - и в админы не ходить.Да нет, хороший админ (по моему определению) как раз случайностей не то чтобы боится, но их не любит. Поэтому предпринимает стопки мер для их избежания и нейтрализации.
>>а дать лишний повод задуматься.
>именно за этим я и качаю траффик с/на опеннет ;)Для этого чем меньше трафика, тем лучше. Как "спамер со стажем" говорю :-/
>Эх.что "Эх"? :)
а чем ping хуже хардбита? (причем, на самом деле я не сказал, что я использую пинг
для определения failovers. Да и кто сказал, что кластеры - это лишь обработка failover?)
>Пример: .....речь шла о нодах одного кластера, который не разбросан (ну, зачастую) по всему миру.
И ситуевину я описал именно для этого.Каждый случай требует своего подхода.
>Да нет, хороший админ (по моему определению) как раз случайностей не то
>чтобы боится, но их не любит. Поэтому предпринимает стопки мер
>для их избежания и нейтрализации.любовь к случайностям никак не противоречит тому, что я сказал
>>Эх.
>что "Эх"? :)
>а чем ping хуже хардбита?"heartbeat", в смысле?
>(причем, на самом деле я не сказал, что я использую пинг
>для определения failovers. Да и кто сказал, что кластеры - это лишь
>обработка failover?)Я, собственно, спрашивал -- Вас лично уже допустили к работе на/по high performance или high availability clusters? Впрочем, ответ уже достаточен...
>>Пример: .....
>речь шла о нодах одного кластера, который не разбросан (ну, зачастую) по
>всему миру. И ситуевину я описал именно для этого.
>Каждый случай требует своего подхода.Среди них есть общие. Ноды люди умные предпочитают бутать не локально, а вообще с сети. Потому как админить их -- удел людей остальных.
Короче, мой тезис -- что все эти "гибкости" нафиг не упёрлись, как только речь заходит о сколь-нибудь промышленных решениях. Потому как там не гибкость важна, а надёжность. Гибкость достаточно хорошо обеспечивается выбором подходящего дистрибутива, зачастую уже заточенного под предметную область.
>"heartbeat", в смысле?он самый
>Я, собственно, спрашивал -- Вас лично уже допустили к работе на/по high
>performance или high availability clusters? Впрочем, ответ уже достаточен...допустили, performance
(сначала прочитал HA, а подумал о HB :)
>Короче, мой тезис -- что все эти "гибкости" нафиг не упёрлись, как
>только речь заходит о сколь-нибудь промышленных решениях. Потому как там
>не гибкость важна, а надёжность.это если цель системы - обеспечивать одну и ту же функциональность какое-то продолжительное время.
А что если у системы цель - менять функционал достаточно быстро?
>Гибкость достаточно хорошо обеспечивается выбором
>подходящего дистрибутива,я об этом говорил изначально :)
Что Генту обеспечивает должную гибкость с минимальными затратами.
>зачастую уже заточенного под предметную область.Угу, а потом задача _немного_ меняется и что, менять дистр?
:)
Дистр - это лишь база. А установленный софт - дело выбора.
>>Гибкость достаточно хорошо обеспечивается выбором
>>подходящего дистрибутива,
>я об этом говорил изначально :)Нет, не об этом.
>Что Генту обеспечивает должную гибкость с минимальными затратами.
Вот у меня сомнения и насчёт "должной" (слишком много нахаляву не бывает), и особенно насчёт "минимальных". И не только у меня, что характерно.
Это не к тому, что оно "плохое", но как в своё время было сказано одному знакомому гентушнику (вот которого в этом году всё же пристроил) -- "не путай профессиональное применение с вознёй над локалхостом".
>>зачастую уже заточенного под предметную область.
>Угу, а потом задача _немного_ меняется и что, менять дистр?
>:)Да, _немного_ менять дистр. Хорошие дистры, специализирующиеся на заданной предметной области, ещё и спасибо за патчи скажут.
>Дистр - это лишь база. А установленный софт - дело выбора.
Дистр бывает базой, бывает платформой. Выбор -- дело оценки ситуации, кругозора, привычки, вкуса и вот того самого профессионализма.
>>Что Генту обеспечивает должную гибкость с минимальными затратами.
>
>Вот у меня сомнения и насчёт "должной" (слишком много нахаляву не бывает),если к этому не стремиться - то и не будет...
>и особенно насчёт "минимальных". И не только у меня, что характерно.сомневаться - право каждого.
Но лично я минимум вычислял между RPM-based дистрами и Гентой.
Если я неправ, что не готов был убивать десятки часов (хотя я все-же пробовал,
и мне даже пришлось изучить как пишутся спеки) на написание и правку
спеков под каждую ситуацию - извините, специфика работы.
Лично мне Гента облегчает жизнь. В этом я не могу быть неправ или же виноват :)
>Это не к тому, что оно "плохое", но как в своё время
>было сказано одному знакомому гентушнику (вот которого в этом году всё
>же пристроил) -- "не путай профессиональное применение с вознёй над локалхостом".не все, что вы сказали кому-то и в прошлом применимо сейчас и в будущем.
Если кто-то в детстве путал право и лево - то вряд ли вы обрадуетесь, если я и вам
напомню не путать такие вещи...
>Да, _немного_ менять дистр. Хорошие дистры, специализирующиеся на заданной предметной области,
>ещё и спасибо за патчи скажут.за патчи много кто спасибо скажет.
Да вот я не считаю разумным тратить силы на нечто узконаправленное.
Вещи общего назначения (как ядро Линукс или всесторонний репозиторий софта),
по мне, так заслуживают большего внимания.
>Но лично я минимум вычислял между RPM-based дистрами и Гентой.
>Если я неправ, что не готов был убивать десятки часов (хотя я
>все-же пробовал, и мне даже пришлось изучить как пишутся спеки)
>на написание и правку спеков под каждую ситуацию - извините, специфика работы.Да при чём тут "извините". Охотно верю, что неподходящим пакетным дистром можно сделать ещё хуже. Особенно при использовании его заместо микроскопа по гвоздям.
Из пакетных перебирать было осмысленно CentOS, Sci, Rock и ALT, насколько могу судить. В альте сейчас кластерное направление потихоньку тоже тронулось, а здешние спеки -- одни из наиболее лаконичных в округе. Если не развесистые "на все случаи жизни", как вот mplayer.spec :)
>Лично мне Гента облегчает жизнь. В этом я не могу быть неправ
>или же виноват :)Разумеется. Вот когда передавать будете, тогда будет второй раунд оценки. Возможно, уже только преемником...
>>Это не к тому, что оно "плохое", но как в своё время
>>было сказано одному знакомому гентушнику (вот которого в этом году всё
>>же пристроил) -- "не путай профессиональное применение с вознёй над локалхостом".
>не все, что вы сказали кому-то и в прошлом применимо сейчас и
>в будущем.Очень многое из того, что я когда-либо кому-либо говорил, применимо и сейчас; очень немного -- было или стало неприменимым. Разумеется, не всё.
>Если кто-то в детстве путал право и лево - то вряд ли
>вы обрадуетесь, если я и вам напомню не путать такие вещи...Почему -- если путаю, то обрадуюсь. Спасибо скажу. Если.
>>Да, _немного_ менять дистр. Хорошие дистры, специализирующиеся
>>на заданной предметной области, ещё и спасибо за патчи скажут.
>за патчи много кто спасибо скажет.
>Да вот я не считаю разумным тратить силы на нечто узконаправленное.Ну-ну. Тратьте по площадям, будьте таким же убитым, как я, ага.
>Вещи общего назначения (как ядро Линукс или всесторонний репозиторий софта),
>по мне, так заслуживают большего внимания.Здесь сложные балансы. Возможно, когда-то Вы лучше поймёте, что я имел в виду, и наоборот.
>Из пакетных перебирать было осмысленно CentOSкроме него, вобщем-то, и выбрать нечего (речь не идет об обазятельной поддержке от RH - за сим и полностью свободный дистр).
>Sci, Rock и ALT, насколько могу
>судить. В альте сейчас кластерное направление потихоньку тоже тронулось, а
>здешние спеки -- одни из наиболее лаконичных в округе. Если
>не развесистые "на все случаи жизни", как вот mplayer.spec :)про развесистые спеки... ;)
вот, допустим, есть 2 спеки на PHP4 и 5, либо же на разные версии этого же
mplayer'a (ах... пардон, или мы считаем, что в дистре допускается лишь одна версия софтины?).
И в своей массе спеки разных версий одной софтины - на 99% одинаковы.
А это - уже логическое выделение общего кода. Библиотеки.
Насколько я знаю (а я плохо знаю спеки) - то в спеках нет возможности использовать описания из других файлов. И все что можно - это лишь описать все в одном файле спеки.
Налицо дублирование кода... что это за собой влечет при поддержке, думаю, Вы вкурсе.У Вам ненавистного портеджа система ебилдов предесмотрела возможность выделения общего кода в библиотеки - eclass'ы.
После этого сами ебилды множества версий PHP или же mplayer'a - крайне просты и коротки.Трудно не увидеть красоту и изысканность такого подхода... ;)
>Разумеется. Вот когда передавать будете, тогда будет второй раунд оценки.
>Возможно, уже только преемником...это происходит намного чаще, чем Вам думается... ;)
Только вот ничего ужасного не происходит :)
>Ну-ну. Тратьте по площадям, будьте таким же убитым, как я, ага.я не имел ввиду поддержку именно огромных наборов софта.
Естественно, сфера моих интересов весьма ограничена.
Но какому набору софта я бы и оказал помощь с своем направлении - так
это портеджу. Весьма всесторонний софт. Как по площади (имена), так и по глубине (версии).
>Здесь сложные балансы. Возможно, когда-то Вы лучше поймёте, что я имел
>в виду, и наоборот.да вобщем-то, логика проста: лучше держать впорядке нечто одно универсальное,
и применять его от нотера до сервака.
Нежели каждый раз начинать искать что-то более подходящее...
>>Из пакетных перебирать было осмысленно CentOS
>кроме него, вобщем-то, и выбрать нечегоЕсть, поскольку от центоса в итоге остаётся довольно немного.
>>Sci, Rock и ALT, насколько могу судить.
>>В альте сейчас кластерное направление потихоньку тоже тронулосьСобсно ftp://ftp.altlinux.org/pub/people/inger/hpc/
https://lists.altlinux.org/mailman/listinfo/hpc-devel>>здешние спеки -- одни из наиболее лаконичных в округе
Собсно вот мнение технического директора Etersoft по этому поводу:
http://lists.altlinux.org/pipermail/smoke-room/2007-December...>>Если не развесистые "на все случаи жизни", как вот mplayer.spec :)
>про развесистые спеки... ;) вот, допустим, есть 2 спеки на PHP4 и 5, либо же на
>разные версии этого же mplayer'a (ах... пардон, или мы считаем, что в дистре
>допускается лишь одна версия софтины?)."В дистре" существует архив всех публиковавшихся версий:
ftp://ftp.altlinux.org/pub/distributions/archive/Sisyphus/in..., по которому можно определить точное местонахождение требуемой сборки в бинарном и исходном виде:
ftp://ftp.altlinux.org/pub/distributions/archive/Sisyphus/&#.../ (хранятся полные снапшоты).Если кому-то приспичило какое-то старьё, то он может вытащить *любую* версию с 2003 года, а не только то, что пожелал оставить в дистфайлах $MAINTAINER, хоть вместе с контекстом. При этом, как правило, усилия прикладываются к тому, чтобы лучшей была текущая сборка.
>И в своей массе спеки разных версий одной софтины - на 99% одинаковы.
Разумеется. Особенно если не принято исправлять проблемы конкретных версий своими, сторонними или бэкпорчеными из $SCM патчами, которые зачастую специфичны для версии или сборки. (кстати, интересно -- что делают майнтейнеры таких пакетов, сводят набор патчей к минимуму, наверное? -- оно и вообще правильно, но не всегда хорошо)
>А это - уже логическое выделение общего кода. Библиотеки.
Библиотеки бывают и ненужные.
Вы о средствах, я о задачах. Для задачи "устроить гадюшник, в котором потом кто угодно ногу сломит" -- гентуу подходит, наверное, действительно намного лучше. Я же вообще предпочитаю сразу разносить по VPS не то, что может потребовать разных версий софта одновременно, а *вообще* *когда-нибудь* может потребовать администрирования другим человеком или выноса на другой хост. Помогает, знаете ли, дебардакизации.
Попросту говоря, я не вижу вокруг задач, которым сильно помогает умение держать несколько сборок параллельно, кроме клинических случаев вроде той же libdb4 или питона, для которых это и так сделано.
>Насколько я знаю (а я плохо знаю спеки) - то в спеках нет возможности использовать
>описания из других файлов. И все что можно - это лишь описать все в одном файле спеки.Иногда делается другой финт ушами -- из одного спека собирается что-нить (например, когда-то был kernel24-source), что потом устанавливается и потом используется из другого спека, но сам предпочитаю избегать таких этажерок (точнее, таких апстримов :).
>Налицо дублирование кода... что это за собой влечет при поддержке, думаю,
>Вы вкурсе.Слушайте, я уже *девять лет* поддерживаю линуксы в количестве уже даже не десятков, а дистрибутивов -- и не вижу *никакого* практического основания под этим Вашим намёком.
Если пытаться умничать и цепляться к словам -- то установка нескольких версий также есть "налицо дублирование кода", причём с отдельным royal PITA по части апдейтов при обнаружении дырок.
Предлагаю завязывать теоретизировать -- и говорить о том, чем занимаетесь, если вообще собираетесь из общения с другими извлекать пользу, в т.ч. себе, а не трепаться ни о чём.
А то иной столько вопросов в минуту задаст, что сто мудрецов за год не ответят...
>У Вам ненавистного портеджа
Да не "ненавистный" он. Смысл эмоций к байтикам? Я всего лишь даю свою оценку как инженер и менеджер объекту Вашей песни.
>система ебилдов предесмотрела возможность выделения общего кода в
>библиотеки - eclass'ы.В RPM есть макросы. См. e.g. http://sisyphus.ru/find.shtml?request=rpm-build- (вообще макропакеты RPM-based дистрибутивов -- одно из основных различий между ними для майнтейнера).
>После этого сами ебилды множества версий PHP или же mplayer'a
>- крайне просты и коротки. Трудно не увидеть красоту и изысканность такого подхода... ;)Вы поподдерживайте как майнтейнер такой портедж с пару лет, да чего-нить используемого, а потом вернёмся к теме об элегантности. Я-то и так давно знаю формулировку "баги древних версий уже и старики забыли", равно как и "приспичило".
>>Разумеется. Вот когда передавать будете, тогда будет второй раунд оценки.
>>Возможно, уже только преемником...
>это происходит намного чаще, чем Вам думается... ;)
>Только вот ничего ужасного не происходит :)Искренне рад :) Может, опишете где опыт для коллег? На том же gentoo-wiki?
А то вот аккуратных слакваристов я знал троих, двое из них уже свалили на дебиан.
>Но какому набору софта я бы и оказал помощь с своем направлении
>- так это портеджу.Ну окажите.
>>Здесь сложные балансы. Возможно, когда-то Вы лучше поймёте, что я имел
>>в виду, и наоборот.
>да вобщем-то, логика проста: лучше держать впорядке нечто одно универсальное,
>и применять его от нотера до сервака.
>Нежели каждый раз начинать искать что-то более подходящее...У меня логика похожая, но балансы действительно другие.
Впрочем, главное -- чтоб работало.
>Впрочем, главное -- чтоб работало.хороший конец хорошего (надеюсь) спора :)
Кто мешает сохранить состояние системы в случае портов?
В случае SRCRPM, я так понимаю, это будет набор спеков. В случае фряхи это /etc/make.conf и /var/db/ports. В случае генту думаю тоже не сложнее.
Так что тут _принципиальной_ разницы не вижу.
>Кто мешает сохранить состояние системы в случае портов?Мне кажется, что вопрос не в принципе, а в стоимости этого самого сохранения.
>В случае SRCRPM, я так понимаю, это будет набор спеков.
Скорее набор src.rpm плюс бутстрап сборочной системы: спеки могут ссылаться на патчи или дополнительные исходники.
>В случае фряхи это /etc/make.conf и /var/db/ports. В случае генту думаю тоже не
>сложнее. Так что тут _принципиальной_ разницы не вижу.Так принципиальной разницы и между слакварью с RHEL нет, и между (кхм) запорожцем с мерседесом...
В случае альта инсталяционный диск для сборочницы и набор скриптов для удобного подсовывания в стиле "а собери-ка мне этот пакетик" был сделан за несколько часов двумя людьми, включая запись и проверку носителей. Я как раз рядом сидел, вылизывал да проверял свою терминальную часть поставки -- исошки тоже автоматически собираются.
Но это, думаю, будет проще и удобнее обсудить и при интересе проверить, когда опубликуют результаты (в смысле дистры) и, так понимаю, сборочную систему (хотя практически всё вплоть до логов сборки и пакета build-environment -- и так уже опубликовано).
PS: правда, это я всё со своей колокольни -- "мы должны отдать заказчику воспроизводимое решение"... на основании набитых в достатке шишек при разных вариантах объехать побыстрей.
>Справился бы ты так же просто, если бы пакетный менеджер был бинарный,
>а не в скриптах, ка к portage?вообще-то FreeBSD порты это не бинарный менеджер
они проще потому как знаний о make файлах и cvs достаточно
чтоб поправить практически любую проблему при сборкев portage же напихали, IMHO, много лишнего (python, xml, ebuild )
Всё это может и имеет смысл. Но учить это, из любви к искусству,
ради того что поставить один пакет лично меня ломает.Беру из distfiles тарбол и ставлю ручками :(
Криво? Да.
Надо не лениться, изучить мат часть что потом спокойно спать - вот как раз в этом случае я не уверен
подобно -> подробно
Пользую gentoo + portage сравнительно недолго (года 1,5), но постоянно нарастающие тормоза portage просто раздражают. Paludis не юзал, но после прочтения материала и комментов появилось желание неприменно попробовать.