Установка ПО в Linux - задача достаточно сложная и по большей части не может контролироваться даже самим пользователем системы. Раньше, когда весь софт компилировался из исходников вручную, это был хоть и долгий, но более управляемый процесс. В дальнейшем появились пакетные менеджеры, такие как rpm и dpkg, которые в силу различия форматов пакетов и репозиториев не могли работать совместно. Более того, предложение по созданию API, который бы внес единообразие в процесс инсталляции ПО, натолкнулось на сопротивление и, не получив поддержки, угасло.
С предложением возобновить создание такого API выступил Denis Washington, один из разработчиков Fedora. Первоначальный проект, под названием Berlin Packaging API, не вызвал энтузиазма и Washington, взявшись за дело собственными руками, написал прототип интерфейса, назвав его LSB Package API (http://www.linuxfoundation.org/en/LSB_Package_API). В основе лежит интерфейс D-Bus и описание пакета в формате XML файла. На данный момент реализация п...URL: http://www.osnews.com/story/19901
Новость: https://www.opennet.ru/opennews/art.shtml?num=16620
>Установка ПО в Linux - задача достаточно сложная и по большей части не может контролироваться даже самим пользователем системы.как страшно жить...
>Установка ПО в Linux - задача достаточно сложная и по большей части не может
>контролироваться даже самим пользователем системы.Уу, охренеть как сложно, особенно в моей кубунте.Жмем K -> add\remove и ставим.Даже по категориям разложено - там мультимедия, а там - графика.Или если крутые запускаем adept или aptitude.А при попытке послушать MP3 плеер сам предложет втулить кодеки :).Вообще, нереально зубодробильно в управлении!
Если у редхата и федоры вечные грабли с софтом, они что, хотят чтобы другие за них решали их проблемы?Лично мне за глаза хватает .deb пакетов для убунты, как и для дебиана а dpkg показал себя достаточно адекватным и удобным пакетным манагером который тем не менее довольно сложно убить.Во всяком случае за 2 года юзания убить его не вышло.Было пару сбоев но он еще и подсказывает как чинить если из консоли пнуть :).Кроме того dpkg в отличие от некоторых других постепенно и плавно эволюционирует а не перекореживается каждый раз до неузнаваемости.И потому в отличие от редхата нет у других этих проблем.Ну вот они и не дергаются.
А вот редхату хочется сказать свое "фи" за то что они постоянно перекореживают свои пакетные манагеры.Они хотят чтобы у всех было так же хреново как у них?Спасибо им большое... но у меня по этому поводу энтузазизма как раз тоже нет.Шли б они в ... с их иксэмэлками и дэбасами.Работает - не трожь!А то потом и у других будет такой же трах с постоянным освоением новых версий пакетных тулзов.Нафиг-нафиг...
>Уу, охренеть как сложно, особенно в моей кубунте.Жмем K -> add\remove и ставим.Даже по категориям разложено - там мультимедия, а там - графика.Или если крутые запускаем adept или aptitude.А при попытке послушать MP3 плеер сам предложет втулить кодеки :).Вообще, нереально зубодробильно в управлении!Только не забывай, что сон разума рождает чудовищ.
>Только не забывай, что сон разума рождает чудовищ.А уж сколько чудовищ рождают программеры... особенно это касается пакетных манагеров редхата, кстати.Я не знаю где там у них разум был но вечными перетрясками своих пакетных манагеров они малость заколебали а rpm в его разных инкарнациях просто ужасен.Что тупорылая структура пакетов что сам манагер.Вот уж кого я не стал бы ставить как эталон в плане пакетных систем так это редхат.Они IMHO представляют из себя отличный пример того как делать НЕ НАДО!И они будут учить других делать пакетные манагеры?!Упаси боже от таких учителей :\
Простите. Но разложите мне пожалуйста,как сей продукт использующего, по пунктам чем rpm так уж сильно отличается от deb к примеру.
>Простите. Но разложите мне пожалуйста,как сей продукт использующего, по пунктам чем rpm
>так уж сильно отличается от deb к примеру.эх ты.. я уж думал что никто не попадется... Или это xcode, видя что никто не начинает спорить сейчас сам с собой от разных ников поспорит?
>Что тупорылая структура пакетов что сам манагер.Уважаемый, Вас тупорыло несёт второе сообщение.
dpkg несколько лучше изначально спроектирован для универсальных применений (тыскыть научный подход), а rpm -- для прикладных (инженерный). Это выливается в разные выборы в подобных ситуациях (например, штатность возможности интерактива при установке отдельного пакета).
А путать редхат, федору, RPM и .rpm в одну кашу в голове -- не следует. При всей моей иронии относительно федоры-то.
2 trey: видите ли, убунтушники в массе своей отличаются не только повальным отсутствием сообразительности, но и тем, что их заразным образом несёт. Вот и этого экземпляра пронесло, а кто-то ведь и купиться может. Можно грохнуть, но бывает лучше объяснить, где неправ -- вдруг дойдёт.
2 blkdog: перевод во многих местах нелокализованный, сильно рекомендую по возможности почитать грамотно изданную литературу на аглицком (не рассылки). E.g. "что не в этом случае" -- видимо, "это не так" (this is not the case). Если хотите, можно попробовать порой в жабере помогать.
>dpkg несколько лучше изначально спроектирован для универсальных применений (тыскыть научный подход), а
>rpm -- для прикладных (инженерный).Интересно, для каких прикладных задач придумывали RPM если на практике и в реальной жизни DEB удобнее?Я например оба пользовал и RPM (несколько разных версий в разных версиях CentOS) мне не понравились.
>А путать редхат, федору, RPM и .rpm в одну кашу в голове
>-- не следует. При всей моей иронии относительно федоры-то.Редхат эту заварушку и заварил.Развели зоопарк да еще постоянно все перетрясают, так что там черт ногу сломит.Почему-то debian based обходятся без такого жуткого бардака.Даже IT OS на Nokia n8x0 использует стандартный манагер пакетов хоть и с своей графической мордочкой к нему, но собственно все свойства дебиановского манагера пакетов - при нем.А консольный вариант вообще ничем таким от десктопных не отличается.Вопрос: кому и нафига при этом кроме редхата надо какое-то непонятное апи если и без него проблем особых нет?
>Вот и этого экземпляра пронесло, а кто-то ведь и купиться может.
Объясняю в чем у вас ошибка: вы выпускаете систему на основе этого ... добра.И потому во первых нечаянно и нисколько не задумываясь делаете им скидку.Сами того не подозревая скорее всего.Во вторых вы все это знаете на уровне гуру и вам кажется что все просто и понятно.Ваша ошибка типична.Не будут люди со стороны делать скидок редхату на их кривульки.И разбираться в всем этом бардаке большей части пользователей и админов обычно неохота.
> Можно грохнуть, но бывает лучше объяснить, где неправ -- вдруг
>дойдёт.А вам можно сказать: у вас неплохая система.Но вот как раз базированность на редхате все портит.Если честно - простите но лично я например не верю в то что у вашей системы большое будущее.Как раз из-за основанности на редхате.Редхат что-то из себя представляет на энтерпрайз поприще а на остальные рынки даже всерьез и не пытается соваться, понимая что не переспективно это с тем что у них есть.Может конечно у вас что-то и получится.Тогда я за вас порадуюсь.Но сам я вашу систему юзал бы дома только если бы она была основана на дебиане или даже лучше (для домашнего использования) убунту.Может редхат и был хорош когда вы начинали делать вашу ос и был лучше других.А сейчас... сейчас редхат что-то из себя представляет только в энтерпрайз секторе.
>Интересно, для каких прикладных задач придумывали RPMПромышленные дистрибутивы, вестимо. Он более деревянный и при этом издревле (v3, что ли) умеет подписи и контрольные суммы.
>>А путать редхат, федору, RPM и .rpm в одну кашу в голове
>>-- не следует. При всей моей иронии относительно федоры-то.
>Редхат эту заварушку и заварил.Да, но с тех пор она кипит довольно замысловато.
>Развели зоопарк да еще постоянно все перетрясают, так что там черт ногу сломит.
Самый большой бардак в rpm world -- это rpm macro hell. Бишь то, что исходный редхатовский набор макросов уж очень убог и просто напрашивается на расширение (будучи прекрасно расширяемым). Дальше каждый танцевал под своё сопровождение :-)
Возможно, это порешают в рамках rpm5.org. Возможно, нет. Не берусь предсказывать.
>Вопрос: кому и нафига при этом кроме редхата надо какое-то непонятное апи
>если и без него проблем особых нет?API чего именно? Впрочем, я всё равно вряд ли отвечу достаточно компетентно, но на своём уровне сборщика и внедренца могу попробовать.
>Объясняю в чем у вас ошибка: вы выпускаете систему на основе этого ... добра.
Есть такое.
>И потому во первых нечаянно и нисколько не задумываясь делаете им скидку.
Подсознательно -- скорее всего, но вообще-то именно выпуская, развёртывая и поддерживая системы на базе чего-либо -- лучше всего знакомишься с проблемами этого чего-либо.
Правда, альтовский rpm очень сильно отличается от редхатовского. Но наш майнтейнер входит в rpm5 team :)
>Во вторых вы все это знаете на уровне гуру и вам кажется что все просто и понятно.
Какого нафиг гуру...
>Ваша ошибка типична.Не будут люди со стороны делать скидок редхату на их кривульки.
И я не делаю, когда речь о кривульках. Хотите -- поищите shigorin|gvy redhat rpm крупноблочный.
Да только ни rpm, ни dpkg как инструменты управления единичными (по сути) пакетами -- где то вооооон там, далеко внизу. Для пользователя низкий уровень -- это apt, ну или там yum какой :-)
>А вам можно сказать: у вас неплохая система.Но вот как раз базированность
>на редхате все портит.Если честно - простите но лично я например
>не верю в то что у вашей системы большое будущее.Как раз
>из-за основанности на редхате.Как бы Вам сказать... вон арабы и евреи -- они и те, и те семиты.
Только почему-то слегка расходятся во взглядах. Так и тут.Если хотите, найдите слово "исходники" здесь:
http://lists.altlinux.org/pipermail/devel/2005-March/031495....
и прочтите абзац, в котором оно находится. Это довольно ёмкое описание.>Редхат что-то из себя представляет на энтерпрайз поприще
>а на остальные рынки даже всерьез и не пытается соваться, понимая
>что не переспективно это с тем что у них есть.У них другие проблемы, как мне кажется. С rpm как техсредством не связанные.
Могу попробовать расписать, но это уже на статью потянет, а сейчас не вполне удобно.>Может конечно у вас что-то и получится.Тогда я за вас порадуюсь.
Спасибо :-)
>Но сам я вашу систему юзал бы дома только если бы она была основана
>на дебиане или даже лучше (для домашнего использования) убунту.На убунте нельзя надёжно основываться, это авторитарный апстрим.
Я в 2005 всерьёз такой вариант для нашей конторы обдумывал и несколько месяцев изучал обстановку. Выводы были сделаны и с тех пор не опровергались :(
>Может редхат и был хорош когда вы начинали делать вашу ос и был лучше
>других.А сейчас... сейчас редхат что-то из себя представляет только в
>энтерпрайз секторе.hint: альт в 2002--2003 сделал многое из того, что было уже сделано в дебиане, а в федоре и opensuse началось только пару лет как. Начиная с мелкоблочной порезки, гораздо менее растяпистого подхода к зависимостям (поскольку в 2001 был внедрён apt параллельно, а потом и вместо *&^&*^ мандрейковского urpmi) и весьма впечатляющей разработки по их автоматическому обнаружению (как сборочных, так и установочных; как для бинарников, так и для скриптовых языков).
Кстати, научная работа по зависимостям в альте тоже не имеет известных мне аналогов ни в одном из известных мне по этой части дистрибутивов. Вместе со своим весьма практическим применением.
Это важно для качества пакетной базы.
>[оверквотинг удален]
>Если у редхата и федоры вечные грабли с софтом, они что, хотят
>чтобы другие за них решали их проблемы?Лично мне за глаза хватает
>.deb пакетов для убунты, как и для дебиана а dpkg показал
>себя достаточно адекватным и удобным пакетным манагером который тем не менее
>довольно сложно убить.Во всяком случае за 2 года юзания убить его
>не вышло.Было пару сбоев но он еще и подсказывает как чинить
>если из консоли пнуть :).Кроме того dpkg в отличие от некоторых
>других постепенно и плавно эволюционирует а не перекореживается каждый раз до
>неузнаваемости.И потому в отличие от редхата нет у других этих проблем.Ну
>вот они и не дергаются.Подтвердите слова свои? Особенно про грабли в федоре с софтом)
>
>А вот редхату хочется сказать свое "фи" за то что они постоянно
>перекореживают свои пакетные манагеры.К примеру когда они их перекореживали?
>Они хотят чтобы у всех было так же
>хреново как у них?Спасибо им большое... но у меня по этому
>поводу энтузазизма как раз тоже нет.Шли б они в ... с
>их иксэмэлками и дэбасами.Работает - не трожь!А то потом и у
>других будет такой же трах с постоянным освоением новых версий пакетных
>тулзов.Нафиг-нафиг...Что вы знаете о deb и rpm?
"Установка ПО в Linux - задача достаточно сложная и по большей части не может контролироваться даже самим пользователем системы."Ха. Как хорощо узнать, что ты не единственный, кто видит кривизну. Осталось подождать пока заметное кол-во людей, наевшись кактусов, начнут спрашивать "а что ты там говорил про управление пакетами прикладного ПО".
>Ха. Как хорощо узнать, что ты не единственный, кто видит кривизну. Осталось
>подождать пока заметное кол-во людей, наевшись кактусов, начнут спрашивать "а что
>ты там говорил про управление пакетами прикладного ПО".По обкурке и не то увидишь. Вопрос не в устанавливаемых пакетах, а в недостаточной единообразности подходов к установке и отсутствию стандартов и договорённостей на эту тему.
> Установка ПО в Linux - задача достаточно сложнаяБред, чего сложного в пакетных менеджерах и их фронтендах? (Типа synaptic)
И с какой это стороны неуправляемо пользователем системы??
Думаю, под неуправляемостью подразумевается тот факт, что после автомагического разрешения 10-20 зависимостей для пакета и установки нужной тебе софтины ты вряд ли вспомнишь, что еще нужно удалить вместе с этим пакетом, чтобы вернуть "все как было". И чтоб ничего не поломать. И чтоб быстро. А пакетов мноооого...
Я слышал, в последней мандриве пакетный менеджер будет определять, что пакет более не используется другими пакетами и предлагать его удаление. Не знаю, как там это будет работать, но грызут сомнения, что не идеально.
бгг, аптитуда уже давно умеет, причем по умолчанию.да и пакман тоже.
но в apt сей функционал почему-то включать не хоят
>но в apt сей функционал почему-то включать не хоята что такое apt-get autoremove ?
emerge в Gentoo по моему неплохо справляется с задачей кдаления неиспользуемых пакетов..
Он думал, - зачем ставить в RedHat, пакет от Ubuntu или от SuSE в Debian???
Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать её в Linux. Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии, мир скоро перейдёт на FreeBSD.
>мир скоро перейдёт на FreeBSD.Не перейдёт, потому что есть ArchLinux, вобравший в себя самые лучшие особенности FreeBSD
>>мир скоро перейдёт на FreeBSD.
>
>Не перейдёт, потому что есть ArchLinux, вобравший в себя самые лучшие особенности
>FreeBSDSlackware тоже нормально.
ИМХО там совсем нет системы этих самых пакаджей. Есть система портов, а это вовсе не одно и то же.
Давно портировали, Gentoo называется. И удаление неиспользуемых пакетов работает.
>Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать
>её в Linux. Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии,
>мир скоро перейдёт на FreeBSD.Ничего хуже системы портов FreeBSD я не знаю. Простая задача: есть самописная софтина, она зависит, ну, например, от стандартного sqlite (не важно). Расскажите, как же мне поставить мою софтину хотя бы на 20 серверов.
Пожалуйста, 7 строчек.PORTNAME= myprog
PORTVERSION= 1.0
CATEGORIES= devel
MASTER_SITES= ftp://local_ftp/LIB_DEPENDS= sqlite3.8:${PORTSDIR}/databases/sqlite3
PLIST_FILES= myprog
.include <bsd.port.mk>
потом touch pkg_descr && make makesum и дальше как угодно
- можно добавить в дерево портов, расшаренное по NFS / в локальное зеркало дерева портов и ставить через for server in "a b c d"; do ssh server "cd /usr/ports/devel/myprog && screen -d -m make install clean"; done
- можно сделать package и сделать то же самое, только с pkg_add -rДля деплоя как раз лучше портов ничего не придумали.
А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты (и их синхронизировать каждый день)? И я еще молчу про то, что библиотеки изредка меняются в пределах одной major.minor версии. И проверить это можно только с помощью getosreldate (здравствуй, статическая линковка!).Собирать на продакшен машинах, конечно, смешная идея, но в некоторых случаях это возможно. Но то, что это будет проходить под рутом (да, я знаю про fakeroot), уже нехорошо.
В случае же, когда программа постоянно меняется, а выкатывается раз в месяц, иногда реже, сборка может продолжаться очень долго. На продакшене. Ага.
Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом. Но сейчас остальные системы куда совершенее.
> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты (и их синхронизировать каждый день)?Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред?
> Собирать на продакшен машинах, конечно, смешная идея
Ничего смешного. Там что, компилятора нет? Или может процессор 486?
> но в некоторых случаях это возможно. Но то, что это будет проходить под рутом (да, я знаю про fakeroot), уже нехорошо.
А вам что там, надо неизвестно чей софт собирать? Тогда пакаджи, все абсолютно аналогично портам.
> В случае же, когда программа постоянно меняется, а выкатывается раз в месяц, иногда реже, сборка может продолжаться очень долго. На продакшене. Ага.
Телепаты в отпуске, угадывать какие у вас там продакшны и какие программы. Собирается долго - ставьте кластер и собирайте на нем.
> Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом. Но сейчас остальные системы куда совершенее.
Да что вы?
Нет, ну это просто феерическое нечто.>> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты
>> (и их синхронизировать каждый день)?
>Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред?Вы всерьёз предлагаете каждый раз собирать? Никогда не слышали про "воспроизводимость сборки" случайно? Что вообще-то код, собранный на одной машине -- может работать на тысячах совершенно других и при этом отладка стека ПО на любой физически исправной из них будет эквивалентна, а не уникальна по надцати параметрам?
>> Собирать на продакшен машинах, конечно, смешная идея
>Ничего смешного. Там что, компилятора нет? Или может процессор 486?Вы всерьёз о компиляторе на продакшене, который не сборочный сервер? Может, ещё самолёты в рейсе модернизировать?
>Телепаты в отпуске, угадывать какие у вас там продакшны и какие программы.
Телепатов у вас там явно нет вообще, так что не надо про отпуск. Гадать тоже не умеете: где продакшен, там очень сильно помогает от головной боли воспроизводимость. А с source-based это свойство не дружит, только с package-based при условии наличия сборочной технологии, включающей создание изолированной воспроизводимой среды сборки и возможности фиксации состояния пакетной базы для этой самой воспроизводимости.
>Собирается долго - ставьте кластер и собирайте на нем.
Под рукой есть три кластера, а вот идиотов, чтобы "собирать на нём" (для чего -- для каждой ноды? или сэр даже слышал про distcc?) -- пока не нашлось.
Так что совет того, бесплатный.
>> Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом.
>> Но сейчас остальные системы куда совершенее.
>Да что вы?Выдыхай, бобёр. Выдыхай. Только осторожно, скрытая камера фиксирует для истории.
Я вот этот образчик так отложу себе в тематическую коллекцию шедевров.
>[оверквотинг удален]
>
>>> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты
>>> (и их синхронизировать каждый день)?
>>Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред?
>
>Вы всерьёз предлагаете каждый раз собирать? Никогда не слышали про "воспроизводимость
>сборки" случайно? Что вообще-то код, собранный на одной машине --
>может работать на тысячах совершенно других и при этом отладка стека
>ПО на любой физически исправной из них будет эквивалентна, а не
>уникальна по надцати параметрам?Ничего не надо собирать на продакшне. делаем пакет на любой доступной машине и пихаем его в пакетный репозиторий.
>>> Собирать на продакшен машинах, конечно, смешная идея
>>Ничего смешного. Там что, компилятора нет? Или может процессор 486?
>Вы всерьёз о компиляторе на продакшене, который не сборочный сервер? Может,
>ещё самолёты в рейсе модернизировать?Вы давно видели фряху? Там компилятор идет из коробки и всегда присутствует в системе.
>>Телепаты в отпуске, угадывать какие у вас там продакшны и какие программы.
>Телепатов у вас там явно нет вообще, так что не надо про
>отпуск. Гадать тоже не умеете: где продакшен, там очень сильно
>помогает от головной боли воспроизводимость. А с source-based это свойство
>не дружит, только с package-based при условии наличия сборочной технологии, включающей
>создание изолированной воспроизводимой среды сборки и возможности фиксации состояния пакетной базы
>для этой самой воспроизводимости.Фиксируйте на здоровье. Поставьте машинку для этих целей или jail поднимите. Там хоть зафиксируйтесь. Создать собственный пакетный репозиторий времени занимает не так много, и делается один раз.
>>Собирается долго - ставьте кластер и собирайте на нем.
>Под рукой есть три кластера, а вот идиотов, чтобы "собирать на нём"
>(для чего -- для каждой ноды? или сэр даже слышал
>про distcc?) -- пока не нашлось.без комментариев.
>Так что совет того, бесплатный.
>>> Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом.
>>> Но сейчас остальные системы куда совершенее.
>>Да что вы?
>Выдыхай, бобёр. Выдыхай. Только осторожно, скрытая камера фиксирует для истории.
>Я вот этот образчик так отложу себе в тематическую коллекцию шедевров.Отложите и подумайте где вы не правы.
>>>> Собирать на продакшен машинах, конечно, смешная идея
>>>Ничего смешного. Там что, компилятора нет? Или может процессор 486?
>>Вы всерьёз о компиляторе на продакшене, который не сборочный сервер? Может,
>>ещё самолёты в рейсе модернизировать?
>Вы давно видели фряху?Недавно последнюю четвёрку хоронил, где был логин, а что?
>Там компилятор идет из коробки и всегда присутствует в системе.
То-то и оно. Могу ещё раз повторить своё утверждение:
"Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?"Впрочем, фрю к продакшен-системам не отношу по ещё более веским причинам, чем компилятор в basesystem -- чуть выше повторялся про бранчи портов.
>Поставьте машинку для этих целей или jail поднимите.
Спасибо, я вчера походя склонировал два и перенёс ещё два контейнера (на поднятые в т.ч. для них машинки).
>Создать собственный пакетный репозиторий времени занимает не так много,
>и делается один раз.Репозитории... "дежурные" генерируются инструментарием после каждой успешной сборки (их бывает и десяток пакетов в день), руками genbasedir тоже порой делаю.
Давайте лучше соглашусь с этими Вашими словами, чем буду развивать тему про репо? :)
> За сборку и тесты на продакшне надо отрывать руки.
> За апгрейд без обкатки на тестовой машине - голову.Только вот ведь какая штука -- инструментально очерченный процесс гораздо более проработан на пакетных линуксах. Бишь вероятность ошибиться неочевидным образом на порядки меньше.
>>Я вот этот образчик так отложу себе в тематическую коллекцию шедевров.
>Отложите и подумайте где вы не правы.Это было сделано в процессе перечитывания перед отправкой.
Как видите, и то отправил, и это.Поясните?
>>Вы давно видели фряху?
>Недавно последнюю четвёрку хоронил, где был логин, а что?Значит давно.
>>Там компилятор идет из коробки и всегда присутствует в системе.
>То-то и оно. Могу ещё раз повторить своё утверждение:
>"Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?"Вам компилятор жить мешает? Ну так на то и source based система,
порты без компилятора как-то.. сами понимаете. Напомню, что порты являются основным
средством установки софта.>Впрочем, фрю к продакшен-системам не отношу по ещё более веским причинам, чем
>компилятор в basesystem -- чуть выше повторялся про бранчи портов.тогда рекомендую заглянуть в них на досуге и увидеть например вот это:
databases/mysql41-client
databases/mysql41-scripts
databases/mysql41-server
databases/mysql50-client
databases/mysql50-scripts
databases/mysql50-server
databases/mysql51-client
databases/mysql51-scripts
databases/mysql51-server
вы всерьез полагаете что там нужны бранчи?>>Поставьте машинку для этих целей или jail поднимите.
>Спасибо, я вчера походя склонировал два и перенёс ещё два контейнера (на
>поднятые в т.ч. для них машинки).Согласен, это проще.
>Репозитории... "дежурные" генерируются инструментарием после каждой успешной сборки (их бывает и десяток пакетов в день), руками genbasedir тоже порой делаю.
И этот десяток прямо-таки необходим в продакшне, и каждый день? Не смешите.
>Давайте лучше соглашусь с этими Вашими словами, чем буду развивать тему про
>репо? :)pkg_create -b и получаем готовый репозиторий со свежепоставленной машины.
или make package в портах.>Только вот ведь какая штука -- инструментально очерченный процесс гораздо более проработан
>на пакетных линуксах.Не совсем понимаю о каком процессе идет речь.
>Бишь вероятность ошибиться неочевидным образом на порядки
>меньше.Как это отменяет сборку и тестирование на отдельном железе?
>>>Я вот этот образчик так отложу себе в тематическую коллекцию шедевров.
>>Отложите и подумайте где вы не правы.
>Это было сделано в процессе перечитывания перед отправкой.
>Как видите, и то отправил, и это. Поясните?Из вашего первого утверждения про снесенную четверку я могу предположить, что вы обсуждаете ось которую можно сказать в глаза не видели. Поэтому подобное высказывание: "фрю к продакшен-системам не отношу по ещё более веским причинам, чем компилятор в basesystem" я склонен не воспринимать всерьез. По своему опыту могу сказать, что люди плюются на фряху больше потому, что она "не как linux", часто не понимая как она живет в реальных условиях и что с ней делать. Я вижу это каждый день.
> Я вижу это каждый
>день.я вот, до недавнего времени, как и Вы видел это каждый день
и знаете -- мне очень надоело... и я таки закончил миграцию с фряхи.P.S. И Вы не поверите.... -- "всё правильно сделал!" (C) Какая-то там страховая компания.
>>>Вы давно видели фряху?
>>Недавно последнюю четвёрку хоронил, где был логин, а что?
>Значит давно.К сожалению, в контексте обсуждаемого вопроса та поросшая мхом немигрируемая 4.10 -- это тоже "недавно".
>>Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?
>Вам компилятор жить мешает?Да. Им можно слишком много начудить локального состояния. Если не задумывались, чем оно плохо -- попробуйте представить себе, что гайки в коробке -- все M5, а не каждая чуть-чуть со своей резьбой.
Вот недавно людям сказал, что компилятора не будет, и предложил собрать пакет со своим индексером. С этим -- помогу. (кстати, надо бы таки помочь)
>Ну так на то и source based система, порты без компилятора как-то.. сами понимаете.
>Напомню, что порты являются основным средством установки софта.Ну так я и поясняю, куда идёт source based и порты в частности -- лесом. Если головняка с поддержкой хочется поменьше, конечно.
>>Впрочем, фрю к продакшен-системам не отношу по ещё более веским причинам, чем
>>компилятор в basesystem -- чуть выше повторялся про бранчи портов.
>тогда рекомендую заглянуть в них на досуге и увидеть например вот это:
>вы всерьез полагаете что там нужны бранчи?Я ещё раз повторюсь: всерьёз полагаюсь, что для осмысленной по усилиям поддержки широкого спектра программ под несколько поддерживаемых веток платформы бранчи _необходимы_.
В качестве нечастой, но яркой иллюстрации -- вспомните, когда последний раз в apache-2.0 одновременно починили дырень и сломали API, а mod_perl2 не успел ещё обновиться.
Бранч и current -- это возможность использовать разный подход при делании изменений: консервативный для бранча, экономично-прогрессивный -- для current. При этом уменьшается плотность конфликтов между теми, кому работать, и теми, кому хакать.
>>Репозитории... "дежурные" генерируются инструментарием после каждой успешной сборки
>>(их бывает и десяток пакетов в день), руками genbasedir тоже порой делаю.
>И этот десяток прямо-таки необходим в продакшне, и каждый день? Не смешите.Зависит.
Просто немного тут участвую в разработке ALT Linux, соответственно минимум три активных репозитория есть практически всегда (current, stable и oldstable), а обычно есть ещё несколько тематических -- например, обновлённые пакеты с LTSP5 и настраивалками, репо с которыми подключается при сборке инсталяционного исошника терминального сервера.
>>Только вот ведь какая штука -- инструментально очерченный процесс гораздо
>>более проработан на пакетных линуксах.
>Не совсем понимаю о каком процессе идет речь.Когда возможно, например, проверить целостность/замкнутость репозитория по тем же библиотекам.
Если интересно -- можете глянуть пример здесь:
http://lists.altlinux.org/pipermail/sisyphus-cybertalk/2008-...
(download неинтересно, а вот unmets и bad_elf_symbols бывают крайне полезны)Это пакет qa-robot (http://sisyphus.ru/srpm/qa-robot). Опирается на apt (работа с репозиторием), который, в свою очередь, у нас опирается на rpm (работа с зависимостями конкретных пакетов).
>>Бишь вероятность ошибиться неочевидным образом на порядки меньше.
>Как это отменяет сборку и тестирование на отдельном железе?Никак не отменяет. То, что порой бывает удобней собирать в контейнере (или на кластере :), а тестировать в qemu -- непринципиальные детали.
Кстати, сборка тут и происходит в сборочных контейнерах :) Начиная с 32/64-битного current (aka Sisyphus).
>>>Отложите и подумайте где вы не правы.
>>Поясните?
>Из вашего первого утверждения про снесенную четверку я могу предположить,
>что вы обсуждаете ось которую можно сказать в глаза не видели.Ну как Вам сказать. Если с 2.2.7 (или 2.2.8?) через 3.4 (или 3.5, что ли) и до 4.10 (или всё-таки 4.11?) нынче считается "в глаза не видел" -- ну ква.
То, что ситуация по конкретно этому вопросу остаётся брежней -- мне и так есть у кого выяснить из тех, чьему мнению и опыту в нём я доверяю (например, netch@).
Поскольку системное администрирование получается побочным занятием относительно манагерства (когда свалить не на кого, приходится делать самому), и не пытаюсь иметь собственный актуальный опыт по всему, что теоретически может подходить для решения наличных задач -- попросту не хватит здоровья.
Кстати, этому же учили в лицее: пользоваться опытом других, не открывая америк.
А выводы примерно десятилетней давности и сегодня остаются очень даже актуальными.
К чему бы это?>Поэтому подобное высказывание: "фрю к продакшен-системам не отношу по ещё более
>веским причинам, чем компилятор в basesystem" я склонен не воспринимать всерьез.Да пожалуйста :-)
>По своему опыту могу сказать, что люди плюются на фряху больше потому,
>что она "не как linux", часто не понимая как она живет в реальных условиях
>и что с ней делать. Я вижу это каждый день.Это чуть другой момент, хотя и примерно двоюродный.
Я прекрасно понимаю, что фря -- не линукс (и несколько понимаю, почему).
А собсно говорю как раз о том, что у линуксов получается на эпоху лучше -- управление установленным программным обеспечением.
Хотите -- спорьте, хотите -- попробуйте посмотреть под другим углом, нежели
"в source-based"...Спорить с умными людьми полезно тем, что узнаёшь что-то новое и излагая то, что знаешь -- находишь в нём неожиданные грани.
Потому на это время и находится порой. :-)
Три кластера под рукой.. Почему сразу не десять?Боже, даже комментировать не хочу. Дешевый непрофессиональный троллинг.
>Три кластера под рукой.. Почему сразу не десять?Потому что СКИТ-1, СКИТ-2, СКИТ-3 -- это три кластера, а не десять. На КПИ-шный не ходок.
>Боже, даже комментировать не хочу. Дешевый непрофессиональный троллинг.
Ну так и не занимайтесь им, или тоже квалифицируйтесь на нормального тролля :-)
[XXXX@ZZZZ ~]$ squeue | awk '{print $2;}' | sort -u
PARTITION
scit1
scit2
scit3На scit3 вон коллега данные для автоматического переводчика обрабатывает :-)
$ squeue | grep pere | wc -l
1560 ядер и 120Gb RAM куда быстрей приводят к появлению и улучшению языковых пар, чем домашняя машинка...
>> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты (и их синхронизировать каждый день)?
> Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред?А pkg_add -r уже научился ходить по разным серверам?
>> Собирать на продакшен машинах, конечно, смешная идея
> Ничего смешного. Там что, компилятора нет? Или может процессор 486?А то, что машина может быть загружена своей основной работой --- это ничего? После сборки надо прогнать тесты, или где--то не так? У тестов (да и у сборки) может быть еще одна большая куча зависимостей. И ее тоже надо будет поставить на продакшен. И следить за версиями.
И, прошу обратить внимание, не надо быть телепатом, что бы это знать.
> Собирается долго - ставьте кластер и собирайте на нем.
Если собирать на кластере, то, наверное потом это надо будет принести с кластера, или во фре уже есть libastral?
>>> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты (и их синхронизировать каждый день)?
>> Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред?
>
>А pkg_add -r уже научился ходить по разным серверам?Вообще-то всегда умел :)
export PACKAGEROOT=ftp://myserver-with-ports.mydomain.ru
pkg_add -r gdbm perl && pkg_add -r bash && pkg_add -r sudo && \
pkg_add -r aspell joe && pkg_add -r lynx && pkg_add -r mc && \
pkg_add -r portaudit
>[оверквотинг удален]
>
>Вообще-то всегда умел :)
>
>export PACKAGEROOT=ftp://myserver-with-ports.mydomain.ru
>
>pkg_add -r gdbm perl && pkg_add -r bash && pkg_add -r sudo
>&& \
>pkg_add -r aspell joe && pkg_add -r lynx && pkg_add -r mc
>&& \
>pkg_add -r portauditЯ тут вижу только один сервер.
>>> Собирать на продакшен машинах, конечно, смешная идея
>> Ничего смешного. Там что, компилятора нет? Или может процессор 486?
>
>А то, что машина может быть загружена своей основной работой --- это
>ничего? После сборки надо прогнать тесты, или где--то не так? У
>тестов (да и у сборки) может быть еще одна большая куча
>зависимостей. И ее тоже надо будет поставить на продакшен. И следить
>за версиями.1) Выделяется отдельный сервер
2) На нем синхронизуются порты
3) Делается сборка нужных портов с помощью portupgrade
Включая свою софтину
4) На этом же сервере можно делать тесты
5) Когда убедились что все работает, тогда ставим на production
Хотя вообще по-хорошему тесты надо делать еще когда пишется софтина :)
mount /usr/ports
portupgrade -aPPR my_program
umount /usr/ports
> Хотя вообще по-хорошему тесты надо делать еще когда пишется софтина :)На некоторые тесты уходят часы.
> mount /usr/ports
> portupgrade -aPPR my_program
> umount /usr/portsНе правда ли проще подключить репозаторий, а потом сказать apt-get/yum?
>>> Собирать на продакшен машинах, конечно, смешная идея
>> Ничего смешного. Там что, компилятора нет? Или может процессор 486?
>А то, что машина может быть загружена своей основной работой --- это
>ничего? После сборки надо прогнать тесты, или где--то не так? У
>тестов (да и у сборки) может быть еще одна большая куча
>зависимостей. И ее тоже надо будет поставить на продакшен. И следить
>за версиями.
>И, прошу обратить внимание, не надо быть телепатом, что бы это знать.За сборку и тесты на продакшне надо отрывать руки.
За апгрейд без обкатки на тестовой машине - голову.
>За сборку и тесты на продакшне надо отрывать руки.
>За апгрейд без обкатки на тестовой машине - голову.Мне это говорить не надо. Говорите это Guest'у, который не видит в этом ничего странного.
> Говорите это Guest'у, который не видит в этом ничего странного.Из каких же моих слов вы сделали такой вывод?
>> Говорите это Guest'у, который не видит в этом ничего странного.
>
>Из каких же моих слов вы сделали такой вывод?Сообщение #42, цитата:
> Собирать на продакшен машинах, конечно, смешная идеяНичего смешного. Там что, компилятора нет? Или может процессор 486?
> За сборку и тесты на продакшне надо отрывать руки.
> За апгрейд без обкатки на тестовой машине - голову.Этого мало!!! Лучше начинать с яиц - безболезненней будет
Да и сам компилятор лучше удалить с продакшин - большенство локальных уязвимостей требуют его.
PS за что и признаны пакетные системы - софт уже идет протестенный. что конечно не отменяет обкатки.
>Да и сам компилятор лучше удалить с продакшин - большенство локальных уязвимостей
>требуют его.Вообще-то нет (и по словам опять же людей, которым склонен верить -- сейчас в основном молодёжь со своими бинарниками шарится), но рассматривание ряда .bash_history наводит на мысль, что мера предосторожности всё равно не лишняя.
Особенно если libc и ядро -- не точь-в-точь убунто-редхатовские, а немного специфичны ;-)
BTW дочитавшим досюда маленький бонус: http://sisyphus.ru/srpm/apache-honeypot
Кхм кхм. Совершенно недавно на работе я таки добился установки bugzilla. На сервак с freebsd - пишу фигню с портом (спасибо сисадмину, помог строчкой) - установило, сиди и пили сколько угодно дальше, потом еще пилил... Установил. Почти. Заняло ~2 часа, должно работать, но там какая-то фигня с сэндмэйлом, которая так и не заработала (лень разбираться).Попробовал на Gentoo. Тоже. Из портов сначала не собралось, потом где-то чего-то подпилили, собралось. Пилил пилил - та же фигня что и во фре с сэндмэйлом. Снова лень разбираться (в генте тоже никогда ничего не делал, да и сервак не мой, экспериментировать сильно не хотел).
Ради чистоты эксперимента попробовал у себя под федорой.
yum -y install bugzilla
а далее - создать пользователя bugs и запустить скрипт багзилловский.
Сорри что много текста лишнего, просто наболело. Я к чему это все - в портах минус: не всегда оно собирается, надо чего-то делать еще. В rpm и deb'ах все куда вероятнее что заработает с полупинка (по крайней мере у меня так).
>Кхм кхм. Совершенно недавно на работе я таки добился установки bugzilla. На
>сервак с freebsd - пишу фигню с портом (спасибо сисадмину, помог
>строчкой) - установило, сиди и пили сколько угодно дальше, потом еще
>пилил... Установил. Почти. Заняло ~2 часа, должно работать, но там какая-то
>фигня с сэндмэйлом, которая так и не заработала (лень разбираться).pkg_add -r <pkgname> или portupgrade -PP <origin>
с сэндмейлом надо понимать на месте. или отключить его и поставить MTA который вы знаете.
>>Кхм кхм. Совершенно недавно на работе я таки добился установки bugzilla. На
>>сервак с freebsd - пишу фигню с портом (спасибо сисадмину, помог
>>строчкой) - установило, сиди и пили сколько угодно дальше, потом еще
>>пилил... Установил. Почти. Заняло ~2 часа, должно работать, но там какая-то
>>фигня с сэндмэйлом, которая так и не заработала (лень разбираться).
>
>pkg_add -r <pkgname> или portupgrade -PP <origin>
>с сэндмейлом надо понимать на месте. или отключить его и поставить MTA
>который вы знаете.Ну там основное время ушло на сборку модулей перла (руками надо было каждую прописывать, а потом, по идее, отвечать на кучу вопросов, но я делал yes2all, и все равно не все установилось). В федоре (в той же) оно сделано иначе. На примере пхп:
чтоб проинсталлировать пхп надо сделать
yum install phpЧтобы подключить поддержку mysql не надо ничего пересобирать или еще чего. Достаточно сделать
yum install php-mysqlТак же и с перлом и остальными.
>Ну там основное время ушло на сборку модулей перла (руками надо было
>каждую прописывать, а потом, по идее, отвечать на кучу вопросов, но
>я делал yes2all, и все равно не все установилось).Случайно не через cpan ставились?
>Чтобы подключить поддержку mysql не надо ничего пересобирать или еще чего. Достаточно
>сделать
>yum install php-mysql
>
>Так же и с перлом и остальными.Чем это сложнее pkg_add -r или portupgrade -PP? оба варианта поставят исключительно бинарный пакет безо всяких пересборок и приплясываний..
>Случайно не через cpan ставились?Да, он.
>Чем это сложнее pkg_add -r или portupgrade -PP? оба варианта поставят исключительно
>бинарный пакет безо всяких пересборок и приплясываний..Типа установлен php, не надо его пересобирать с флагом --with-gd (к примеру), а можно сделать что-то вроде yum install php-gd2? типа pkg_add -r php-gd2? (чисто интуитивно)
>>Случайно не через cpan ставились?
>Да, он.тогда получаете кучу вопросов и не факт что соберется. ставьте портом.
>>Чем это сложнее pkg_add -r или portupgrade -PP? оба варианта поставят исключительно
>>бинарный пакет безо всяких пересборок и приплясываний..
>
>Типа установлен php, не надо его пересобирать с флагом --with-gd (к примеру),
>а можно сделать что-то вроде yum install php-gd2? типа pkg_add -r
>php-gd2? (чисто интуитивно)portupgrade -PP graphics/php5-gd (или graphics/php4-gd)
Для pkg_add нужно знать точное имя пакета. можно посмотреть в порту.
>>а можно сделать что-то вроде yum install php-gd2? типа pkg_add -r
>>php-gd2? (чисто интуитивно)
>portupgrade -PP graphics/php5-gd (или graphics/php4-gd)
>Для pkg_add нужно знать точное имя пакета. можно посмотреть в порту....что снова возвращает нас к вопросу, "Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"?? :-))))
> Мне кажется весьма удобной система пакаджей во FreeBSDНет системы пакаджей, есть система портов. А бинарные пакаджи, которые из нее получаются, не очень то и удобны.
> пора бы портировать её в Linux
Гентушный portage в некотором смысле аналог, хотя у него есть смои большие плюсы и большие минусы
pkgsrc можно использовать вообще почти везде, от linux до solaris, он к портам гораздо ближе.Вообще дело не в этом. Дело в том имхо, что любая система пакетов должна основываться на исходниках, но при этом уметь порождать самодостаточные бинарные пакеты. Это значит, что не maintainer'ы не собирают пакеты как хотят, а пишут инструкцию, как пакет собрать (аналог порта FreeBSD или ebuild'а), после чего добавляют ее в репозиторий. Заодно могут залить и сам пакет, по ней собранный.
Итого: имеем все плюсы source-based систем. Автоматизированная проверка и сборка подо все архитектуры, возможность быстро обновить порт до новой версии (просто взяв существующий и изменив циферку) и т.д. В то же время из этого должны получаться пакеты, которые как минимум знают, с какими версиями зависимых пакетов они могут работать. FreeBSD'шные пакаджи, например, не знают. Будут писать ворнинги, если версии не совпадают, и если, например, shared lib версия поменялась или еще какой косяк, ничего сделать не cмогут.
Ну и системная библиотека для управления этим всем, чтобы любой пакет можно было установить одной командой, причем установка из исходников/бинарников меняется одним ключиком.Короче, потенциально есть куда развиваться всем существующим пакетным менеджерам, но то, что `Установка ПО в Linux - задача достаточно сложная', и идеи о новом API, основанном на D-BUS (!!!) и XML - такой концентрированный параноидальный бред, что мне даже страшно.
>Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать
>её в Linux.Дмитрий, от Вас не ожидал.
Во-первых, пакетные системы в линуксах -- как минимум apt -- на порядок более развиты, чем зачаточная пакетная система FreeBSD. Можете поискать да хотя бы и в архивах r.o.c разборы полётов :-)
Во-вторых, _портаджи_ в Gentoo и ряде подобных дистров тоже есть и несмотря на улучшения относительно портов FreeBSD -- продолжают иметь ряд принципиальных и архитектурных проблем оригинала (например, отсутствие бранчей по версиям поддерживаемых дистрибутивов, когда желательно поддерживать их в режиме минимальных изменений).
В-третьих, порты даже в той же NetBSD по последнему пункту сделаны куда грамотней, чем во фряке.
Когда кажется -- креститься пора :-)
>Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии,
>мир скоро перейдёт на FreeBSD.Бздюшники пытались жёстко гнобить тех, кто нарушил даже не текст их лицензии, а то, что они себе возомнили. Всё равно за бортом.
Впрочем, не верьте мне на слово -- просто смотрите внимательно сами.
>Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать
>её в Linux. Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии,
>мир скоро перейдёт на FreeBSD.Система пакаджей во фряхе довольно убога:
1. Пакетная база - набор каталогов с информацией о структуре и содержимом пакета. На большом количестве установленного софта начинаются заметные тормоза, так как упираемся в дисковую подсистему.
2. Жесткие зависимости. т.е. при обновлении пакета на который ссылается другой пакет получаем битую зависимость.
3. Отсутствие апгрейда как такового.Система портов тоже не без недостатков. В частности:
1. Приходится долго и аккуратно подгонять make.conf под свои нужды, чтобы собраться скажем именно с апачем версии 2.0 и с нужными опциями, которые не всегда можно получить по make config(но присутствуют в Makefile порта).
2. Зачастую невозможно собрать два пакета с разными опциями с одного порта и сложить в один пакетный репозиторий, т.к. имена таких пакетов вероятнее всего совпадут. Бывают правда и исключения например для опции WITH_THREADS.
3. Апгрейд никакой.Вобщем для _пользователя_ подобная схема в большинстве случаев неприемлема. Все это более или меннее лечится portupgrade и ижи с ними, но знакомым точно не поставлю. Хотя сам фряшник и гибкость портовой системы покрывает все эти недостатки.
Из плюсов могу отметить гибкость портовой системы и _предсказуемость_ поведения как портов так и пакетов. Для админа эти плюсы легко перевешивают все минусы перечисленные выше.
>Система пакаджей во фряхе довольно убога:
>1. Пакетная база - набор каталогов с информацией о структуре и содержимом
>пакета. На большом количестве установленного софта начинаются заметные тормоза, так как
>упираемся в дисковую подсистему.
>2. Жесткие зависимости. т.е. при обновлении пакета на который ссылается другой пакет
>получаем битую зависимость.
>3. Отсутствие апгрейда как такового.Обновлений нет.
А раз так, то в пункте 2 написана фигня - "при обновлении пакета". При каком обновлении ?Получить битую зависимость можно если удалить пакет с ключом "force".
Иначе pkg_delete просто не даст удалить пакет если есть зависящие от него.
Ну а раз использовал "force" - то наверное знал что делаешь ? :)
>Система портов тоже не без недостатков. В частности:
>1. Приходится долго и аккуратно подгонять make.conf под свои нужды, чтобы собраться
>скажем именно с апачем версии 2.0 и с нужными опциями, которые
>не всегда можно получить по make config(но присутствуют в Makefile порта).А зачем подгонять make.conf ?
Нужно использовать
1) make config
2_ portupgrade c pkgtools.conf - там прописывают все остальные опции которые не входят в конфиг.Да один раз нужно создать /var/db/ports/ и pkgtools.conf под себя.
Но скажем если взять rpm-based и debian-based - то там опции сборки уже решены за вас
и если вы захотите делать часть пакетов со своими опциями сборки,
то проблем будет не меньше чем в FreeBSD.>
>2. Зачастую невозможно собрать два пакета с разными опциями с одного порта
>и сложить в один пакетный репозиторий, т.к. имена таких пакетов вероятнее
>всего совпадут. Бывают правда и исключения например для опции WITH_THREADS.Да - это проблема в FreeBSD.
Нельзя собрать два конфликтующих пакета. Cам с собой пакет конфликтует по определению.
Имена пакетов в принципе можно разрулить подправив Makefile.
Но вот в FreeBSD сделано так, что для сборки пакета его нужно обязательно установить.
И это мешает.>3. Апгрейд никакой.
>
>Вобщем для _пользователя_ подобная схема в большинстве случаев неприемлема. Все это более
>или меннее лечится portupgrade и ижи с ними, но знакомым точно
>не поставлю. Хотя сам фряшник и гибкость портовой системы покрывает все
>эти недостатки.portupgrade хорошая вещь, но все равно не решает всех проблем.
>[оверквотинг удален]
>>3. Отсутствие апгрейда как такового.
>
>Обновлений нет.
>А раз так, то в пункте 2 написана фигня - "при обновлении
>пакета". При каком обновлении ?
>Получить битую зависимость можно если удалить пакет с ключом "force".
>Иначе pkg_delete просто не даст удалить пакет если есть зависящие от него.
>
>Ну а раз использовал "force" - то наверное знал что делаешь ?
>:)гхм csup на /usr/ports и обновляемся за порта. а заодно получаем битую зависимость. Сюрприз.
>>Система портов тоже не без недостатков. В частности:
>>1. Приходится долго и аккуратно подгонять make.conf под свои нужды, чтобы собраться
>>скажем именно с апачем версии 2.0 и с нужными опциями, которые
>>не всегда можно получить по make config(но присутствуют в Makefile порта).
>А зачем подгонять make.conf ?
>Нужно использовать
>1) make config
>2_ portupgrade c pkgtools.conf - там прописывают все остальные опции которые не
>входят в конфиг.1. make config, как я уже написал не всегда содержит _все_ опции доступные в Makefile. И еще не для всех портов существует.
2. portupgrade не покрывает случаи когда я говорю make install в самом порту. Если это не апгрейд, то portupgrade никакого смысла использовать нет. make.conf _всегда_ предпочтительнее чем конфиг сторонней тулзы.>Да один раз нужно создать /var/db/ports/ и pkgtools.conf под себя.
Это хорошо для одной машины. т.к. подразумевает определенный интерактив.(make config)
>Но скажем если взять rpm-based и debian-based - то там опции сборки
>уже решены за вас
>и если вы захотите делать часть пакетов со своими опциями сборки,
>то проблем будет не меньше чем в FreeBSD.Проблем будет гораздо больше, так как заточены на пакеты.
>>2. Зачастую невозможно собрать два пакета с разными опциями с одного порта
>>и сложить в один пакетный репозиторий, т.к. имена таких пакетов вероятнее
>>всего совпадут. Бывают правда и исключения например для опции WITH_THREADS.
>
>Да - это проблема в FreeBSD.
>Нельзя собрать два конфликтующих пакета. Cам с собой пакет конфликтует по определению.
>Имена пакетов в принципе можно разрулить подправив Makefile.
>Но вот в FreeBSD сделано так, что для сборки пакета его нужно
>обязательно установить.Собрать можно например в chroot(DESTDIR=<chroot path> -DCHROOTED), сложить нельзя.
>portupgrade хорошая вещь, но все равно не решает всех проблем.
Он не решает даже половины реальных проблем если я захочу работать с пакетной базой в полностью автоматическом режиме - без собственного непосредственного участия. Смею заверить, напильник больше похож на собственную портовую систему.
> Получить битую зависимость можно если удалить пакет с ключом "force".
> Иначе pkg_delete просто не даст удалить пакет если есть зависящие от него.Еще можно запустить portupgrade. Даже в мане написано:
> After performing a binary upgrade, it is strongly recommended that
> you run ``pkgdb -F'' to fix broken dependencies introduced by the
> newly installed packages.t
Зачем создавать ещё одну прослойку для линукса, и без того проблем хватает. Самая лучшая (но конечно не самая удобная и простая) установка пакетов реализована в slackware. Это предел простоты, и вот это должно быть примером для всех создателей дистрибутивов.
Не самая лучшая. Недавно решил удалить ненужные пакеты и понял, что не знаю, как.
Ну покоцал, конечно, те, которые знаю, что точно не нужны. А сколько осталось lib*super-puper*.tgz и представить боюсь :)
>Не самая лучшая. Недавно решил удалить ненужные пакеты и понял, что не
>знаю, как.
>Ну покоцал, конечно, те, которые знаю, что точно не нужны. А сколько
>осталось lib*super-puper*.tgz и представить боюсь :)Если ставишь через пакет, то и удаляешь removepkg. А то что make install DESTDIR= и затем makepkg это уж каждый кто устанавливает slackware должен знать сразу.
>>Не самая лучшая. Недавно решил удалить ненужные пакеты и понял, что не
>>знаю, как.
>>Ну покоцал, конечно, те, которые знаю, что точно не нужны. А сколько
>>осталось lib*super-puper*.tgz и представить боюсь :)Ктому же есть /var/adm/packages
Спасибо, как устанавливать и удалять пакеты я сам знаю :)
Речь о другом:
https://www.opennet.ru/openforum/vsluhforumID3/42532.html#10
> это уж каждый кто устанавливает slackware должен знать сразу.Видите ли, те деятели, которые бегают и орут "слакарулит", это не склонны своим доверчивым жертвам рассказывать.
Почему бы последние были "должны"? Если я кому-то что-то впариваю, так это _я должен_ рассказать про подводные грабли, а не человек -- догадываться или впитать с молоком матери.
Следствие: не утруждаетесь рассказывать -- не впаривайте, имейте совесть.
>Зачем создавать ещё одну прослойку для линукса, и без того проблем хватает.[*]
>Самая лучшая (но конечно не самая удобная и простая)А чем лучшая-то? Она ведь ещё и не самая надёжная.
>установка пакетов реализована в slackware. Это предел простоты
Не простоты, а примитивности.
>и вот это должно быть примером для всех создателей дистрибутивов.
Вы мож сперва проблемы, которых хватает, порешайте? А потом нам, убогим создателям дистрибутивов, придёте и расскажете чего-нить умного.
Для начала предлагаю http://lafox.net/support/index.php?showtopic=11769
>Вы мож сперва проблемы, которых хватает, порешайте? А потом нам, убогим
>создателям дистрибутивов, придёте и расскажете чего-нить умного.Вы дистрибутивы без обратной связи с конечными пользователями делаете? Может быть убогие пользователи чего и подсказали бы :). Насчёт slackware - мне хватает её уровня сложности (если хотите примитивности). Изучать что-то ещё мне нехватает времени. Пусть например CentOS хороший дистрибутив, но я не собираюсь мёрзнуть в серверной управляя через графику (вообще X на серверах не держим), или растаскивать симлинки в rc.d вручную. Возьмём примитивнейший пример настройки сетевого интерфейса. Я знаю где лежит конфигурационный файл, но он пуст. Крутые дистростроители забыли предложить шаблон хотя бы в виде комментариев. Я что должен из-за такой фигни хэндбуки курить? Так что почаще с пользователями советуйтесь.
>>Вы мож сперва проблемы, которых хватает, порешайте? А потом нам, убогим
>>создателям дистрибутивов, придёте и расскажете чего-нить умного.
>Вы дистрибутивы без обратной связи с конечными пользователями делаете?Ну почему же. Отвечать могу только за себя -- стараюсь слушать, хотя тоже порой в своп ухожу :)
>Может быть убогие пользователи чего и подсказали бы :)
У нас обычно очень даже ничего пользователи, иной раз интереснейшие вещи рассказывают ;)
>Насчёт slackware - мне хватает её уровня сложности (если хотите примитивности).
>Изучать что-то ещё мне нехватает времени.Подсказать, почему не хватает, или сами догадаетесь? Попробуйте сопоставить время на решение задачи и время на возню с системой, не направленное непосредственно на решение этой самой задачи.
Сам-то как раз много "вожусь с системой", но поскольку это в основном пакеты и профили дистрибутивов, которые публикуются -- толку от такой возни бывает больше, чем на localhost.
>Пусть например CentOS хороший дистрибутив, но я не собираюсь мёрзнуть
>в серверной управляя через графику (вообще X на серверах не держим),
>или растаскивать симлинки в rc.d вручную.Ну кто ж заставляет-то. Да и ssh -X/-Y не отменяли, если кого угораздило держать.
>Возьмём примитивнейший пример настройки сетевого интерфейса.
Давайте.
>Я знаю где лежит конфигурационный файл, но он пуст.
Не очень хорошо.
>Крутые дистростроители забыли предложить шаблон хотя бы в виде комментариев.
Повесите им багу, если будет время? (правда, скорее всего пошлют в редхат, но это уж судьба клонов)
>Я что должен из-за такой фигни хэндбуки курить?
Стоп. Я согласен, что ситуация плохая и нехорошая. Вы не пояснили, как это делаете на слаквари и чем именно получается легче (не стоит путать с "привычней").
Hint: сделать слакварь из кентоса несколько проще, чем обратное. В данном разе ничто не мешает Вам пойти в /etc/{rc.d/,}rc.local и соорудить там нужный вид из modprobe, ifconfig и route (и/или на ip -- по вкусу и надобности).
Точно так же и любая другая настраивалка. Я вот до сих пор одним из первых дел выношу из создаваемых контейнеров alterator (который положил в заготовку), но надеюсь через годик эту привычку уже отменять -- поскольку надо же сделать удобный и обозримый интерфейс для управления OpenVZ VE (а то и другими видами контекстов) на своих же системах, ну не век же в голове столько контексту держать...
(ещё хинт -- необязательно хэндбуки, можно fgrep -r ifcfg /usr/share/doc)
>Так что почаще с пользователями советуйтесь.
Давайте посоветуемся. Только сразу предупреждаю, к CentOS/RHEL у меня отношение тоже ироничное, хоть и по другим поводам :-) А в ALT стараюсь делать так, чтоб было удобно и полезно себе и другим. И это скорее правило по команде (хотя бывают заскоки, конечно).
>Подсказать, почему не хватает, или сами догадаетесь? Попробуйте сопоставить время на
>решение задачи и время на возню с системой, не направленное непосредственно
>на решение этой самой задачи.
>Давайте посоветуемся. Только сразу предупреждаю, к CentOS/RHEL у меня отношение тоже
>ироничное, хоть и по другим поводам :-) А в ALT
>стараюсь делать так, чтоб было удобно и полезно себе и другим.
> И это скорее правило по команде (хотя бывают заскоки, конечно).
>Давайте посоветуемся и про затраченное время.
ALT не видел, говорят хороший дистрибутив, посмотрю в ближайшее время. Загрузчик надеюсь предлагается запаролить при установке? Интересно как там у Вас со сборкой например зависимостей glibc->samba скажем с march=nocona.
>ALT не видел, говорят хороший дистрибутив[...]
>Интересно как там у Вас со сборкой например[...]
>скажем с march=nocona.:-O То есть _не_ сорс-бейзеd дистрибутивов Вы вообще не видели? Мама-мама-мама...
>:-O То есть _не_ сорс-бейзеd дистрибутивов Вы вообще не видели? Мама-мама-мама...А что мне march=i486 mtune=i686 на сервер что ли ставить где 300 пользователей файлы гоняют самбой чараз кламав, да ещё жестоко VSS? Видел, на ноуте неплохо смотрятся.
>Давайте посоветуемся и про затраченное время/me listens
>Загрузчик надеюсь предлагается запаролить при установке?
В допнастройках -- хоть руками конфигурацию написать.
>Интересно как там у вас со сборкой например зависимостей glibc->samba скажем
>с march=nocona.Не уловил смысл, но можете поставить эксперимент -- hasher помогает.
ftp://ftp.altlinux.org/pub/people/ldv/hasher/hasher.7.html
ftp://ftp.altlinux.org/pub/people/ldv/hasher/thesis-2004.htmlВообще самбу у нас собирает один из участников Samba Team -- проблемы последнее время бывали разве что вида "Саша медлит с релизом-с-буковкой, говоря, что там ещё сейчас патчик будет" :-)
лучше всего в solaris :)
никаких менеджеров - голова, блокнот и прямые руки :D
> лучше всего в solaris :)
> никаких менеджеров - голова, блокнот и прямые руки :D+1; Очень просто, не отягощено гипертрофированными зависимостями
(и, когда я с ним работал, никаких навязчивых update'ов,
приводящих систему с публичными сервисами в непредсказуемое
состояние).
>> лучше всего в solaris :)
>> никаких менеджеров - голова, блокнот и прямые руки :DЭто простое человеческое щастье доступно пожалуй что на любом unix-like ;) чем лучше-то?
>+1; Очень просто, не отягощено гипертрофированными зависимостями
Не переживайте, солярку уже пытаются привести в вид, приличный современному линуксу ;)
Вряд ли это что-то решит. У Линуха должен быть свой собственный API для установки ПО. Иначе все поставщики его дистрибутивов так и будут продолжать лепить свои установщики
>Вряд ли это что-то решит. У Линуха должен быть свой собственный API
>для установки ПО.Если в итоге получится такое же глюкавое говнище как MSI инсталлер которое встает колом на каждый пшик, почти нихрена не умеет (кроме как глючить) и с массой ограничений - не, нафиг-нафиг.Линукс хорош выбором и тем что в итоге можно выбрать и что-то стоящее и нужное именно мне и именно в конкретно моих задачах порой.Вы такие умные?А покажите какую-нить систему под которую софта больше чем под .deb и .rpm?Всего 2 манагера пакетов кстати.
>Если в итоге получится такое же глюкавое говнище как MSI инсталлер которое
>встает колом на каждый пшик, почти нихрена не умеет (кроме как
>глючить) и с массой ограничений - не, нафиг-нафиг.Линукс хорош выбором и
>тем что в итоге можно выбрать и что-то стоящее и нужное
>именно мне и именно в конкретно моих задачах порой.Может говнище и глюкавое, но от транзакций на unix like осях лично я бы не отказался.
>от транзакций на unix like осях лично я бы не отказался.Для меня apt+rpm обеспечивают два уровня:
- rpm умеет обломить транзакцию в несколько пакетов вплоть до момента проверки на пересечение устанавливаемых/обновляемых пакетов на пересечения по файлам;
- rpm умеет обломить (откатить) установку одного пакета, если вдруг упёрлись в место/квоту/бэд/битый пакет (бишь он сперва распаковывает в файлы со случайными суффиксами и только если всё распаковалось -- unlink() старое);
- apt умеет обломить транзакцию по куче условий верхнего уровня (например, исчезновение нужного какому из пакетов soname из системы);
- apt умеет откатываться на пакеты с определёнными свойствами (pin-priority) -- впрочем, этим пользовался очень давно и нечасто, как-то не привык.Как с первыми двумя пунктами у dpkg -- не доводилось выяснять (это всё-таки редкие случаи), но можно предположить, что где-то сопоставимо.
Вот с откатом действий, производимых пакетными скриптами, может быть полный нетривиал. В смысле чтение их глазами да соображание, что было и что стало.
>Вот с откатом действий, производимых пакетными скриптами, может быть полный нетривиал.
>В смысле чтение их глазами да соображание, что было и что
>сталов этом и заключается основная проблема. Как быть если я хочу поставить несколько пакетов в одной "транзакции"? при обломе я хочу откатиться на состояние до начала установки/апгрейда..
>>Вот с откатом действий, производимых пакетными скриптами, может быть полный нетривиал.
>>В смысле чтение их глазами да соображание, что было и что стало
>в этом и заключается основная проблема.Вопрос, как обычно -- в том, какая именно проблема стоит и сколько готовности её решать.
>Как быть если я хочу поставить несколько пакетов в одной "транзакции"?
См. выше, тут это выходит в основном к apt и отчасти к rpm (насчёт пересечений).
>при обломе я хочу откатиться на состояние до начала установки/апгрейда..
Облом бывает разноплановый: одно дело откатить версии пакетов (это элементарно), другое -- например, "провернуть назад" фарш обновлённой базы данных после пинка в ребилдилку из постустановочного скрипта. Или вот ещё один из частных примеров: https://bugzilla.altlinux.org/show_bug.cgi?id=14917 (rpm умеет после транзакции выполнить предварительно заданный код -- например, перестройку собственной базы; это и имелось в виду под post mortem).
Бишь задача поиска обратной функции к произвольной (а именно к ней сводится вопрос отката действий скриптов) -- боюсь, нерешаемая "в лоб".В более-менее общем случае при условии пренебрежимости в разнице по остальному находящемуся на той же ФС состоянию[*]... наверное, я бы копал в сторону XFS/LVM snapshots.
* бишь пользователи или там базы могут и должны жить на других ФС, нежели пакетное ПО,
если уж актуальна такая точность/гарантированность отката состоянияНо до сих пор хватало даже не аптовых pin'ов, а rpm -Uvh --oldpackage, благо случаи редки и происходят там, где и ожидаются (в основном unstable на буке).
Кстати, на практике с этим тоже контейнеры помогают: делаешь клон, изучаешь процесс в деталях, но без риска уронить production, и если всё устраивает -- можно перекинуть адреса и оставить старую VE-шку в качестве бэкапа, пока пыль точно не осядет.
> Вряд ли это что-то решит. У Линуха должен быть свой собственный API для установки ПО.
> Иначе все поставщики его дистрибутивов так и будут продолжать лепить свои установщикиЕсть мнение, что <<ужасное>> состояние инсталляции под Linux не идёт ни в какое сравнение с инсталляцией на W. С _любым_ PM (или без него) я способен найти приемлемый для меня use-case. Количество вариантов-кандидатов всегда > 1.
> Установка ПО в Linux - задача достаточно сложная и по большей части не может контролироваться даже самим пользователем системы.Черт возьми. Ну доколе?! Откуда берутся эти идиоты и откуда они берут такие сложности?
- Линукс для дома - ubuntu. Synaptic - любой пакет ищется, скачивается и устанавливается/обновляется со всем зависимостями в пару кликов. Либо одной командой apt для которой надо помнить только 3 флага.
- Не десктопная FreeBSD. Любой порт ищется, устанавливается, скачивается/обновляется также одной командой, либо также одним кликом через GUI к портам (забыл уже как оно зовется).
В gentoo все ничем не сложнее, и подозреваю что в остальных mainstream дистрибутивах тоже. Бывшие Windows пользователи ОХРЕНЕВАЮТ, что ВЕСЬ софт ставится единообразно и мгновенно, и, при этом чисто потом удаляется.
Так нет, обязательно вылезет чудо, которое придумает свой суперпростой формат пакетов. Хорошим тоном у них еще считается все зависимости статически прилинковать, ага. Ну и найдется еще пачка странных людей, которые им поддакнут (см. посты #17 и #20). `Да-да, скажут, Linux для гиков, на любой чих ./configure надо и ядро пересобрать'.
Научитесь думать мозгом, а пока проходите и не задерживайте.
>Так нет, обязательно вылезет чудо, которое придумает свой суперпростой формат пакетов.Не просто суперпростой, а особенно суперпростой с XML и бантиками.
>Хорошим тоном у них еще считается все зависимости статически прилинковать, ага.
Ну эт скорее у слакваристов навроде rоdlinuх.
Вообще же тем, для кого synaptic сложен -- в новом распрекрасном мире показаны Wii/Xbox/PS3, мобила и тырнет-таблетка. И никаких универсальных программируемых расширяемых компьютеров.
Появится еще один бажный линуксовый пакет. Мне так линукс давно интересен только как встраиваемая система, в пользовательскую десктоп систему, я считаю, он не вырастет никогда. Ну а если ты например ставишь систему на какой-нить Colibri PXA и еще не врубился как собрать и проинсталить пакет, то тут уж ничего не поможет.
>Появится еще один бажный линуксовый пакет. Мне так линукс давно интересен только
>как встраиваемая система, в пользовательскую десктоп систему, я считаю, он не
>вырастет никогда.Уже выросла, осталось "привыкнуть" народу к ней. Действительно много людей (из моего круга общения) либо перешли либо переходят и довольны.
А насчет:
> Ну а если ты например ставишь систему на какой-нить
>Colibri PXA и еще не врубился как собрать и проинсталить пакет,
>то тут уж ничего не поможет.- почему бы в таком случае не сделать вариант "деньги за поддержку". Вы отваливаете раз в месяц сис. админу, который периодически помогает вам и консультирует вас. На бедно-студенческом уровне это вообще что-то типа "пиво за поддержку" :-)
Мне все же кажется создовать такой Ари надо ,но для РАЗРАБОТЧИКОВ программ .Например есть
Такая програма как Firefox - хочеш установить обновление или дополнение ...хм если в пакетах нет то радости писать rpm что то не испытываю .