URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 42532
[ Назад ]

Исходное сообщение
"OpenNews: Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"

Отправлено opennews , 24-Июн-08 16:13 
Установка ПО в 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
Новость: http://www.opennet.me/opennews/art.shtml?num=16620


Содержание

Сообщения в этом обсуждении
"Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"
Отправлено trey , 24-Июн-08 16:13 
>Установка ПО в Linux - задача достаточно сложная и по большей части не может контролироваться даже самим пользователем системы.

как страшно жить...


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено xcode , 24-Июн-08 21:25 
>Установка ПО в Linux - задача достаточно сложная и по большей части не может
>контролироваться даже самим пользователем системы.

Уу, охренеть как сложно, особенно в моей кубунте.Жмем K -> add\remove и ставим.Даже по категориям разложено - там мультимедия, а там - графика.Или если крутые запускаем adept или aptitude.А при попытке послушать MP3 плеер сам предложет втулить кодеки :).Вообще, нереально зубодробильно в управлении!

Если у редхата и федоры вечные грабли с софтом, они что, хотят чтобы другие за них решали их проблемы?Лично мне за глаза хватает .deb пакетов для убунты, как и для дебиана а dpkg показал себя достаточно адекватным и удобным пакетным манагером который тем не менее довольно сложно убить.Во всяком случае за 2 года юзания убить его не вышло.Было пару сбоев но он еще и подсказывает как чинить если из консоли пнуть :).Кроме того dpkg в отличие от некоторых других постепенно и плавно эволюционирует а не перекореживается каждый раз до неузнаваемости.И потому в отличие от редхата нет у других этих проблем.Ну вот они и не дергаются.

А вот редхату хочется сказать свое "фи" за то что они постоянно перекореживают свои пакетные манагеры.Они хотят чтобы у всех было так же хреново как у них?Спасибо им большое... но у меня по этому поводу энтузазизма как раз тоже нет.Шли б они в ... с их иксэмэлками и дэбасами.Работает - не трожь!А то потом и у других будет такой же трах с постоянным освоением новых версий пакетных тулзов.Нафиг-нафиг...


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Анонимус , 24-Июн-08 22:10 
>Уу, охренеть как сложно, особенно в моей кубунте.Жмем K -> add\remove и ставим.Даже по категориям разложено - там мультимедия, а там - графика.Или если крутые запускаем adept или aptitude.А при попытке послушать MP3 плеер сам предложет втулить кодеки :).Вообще, нереально зубодробильно в управлении!

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


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено xcode , 24-Июн-08 22:21 
>Только не забывай, что сон разума рождает чудовищ.

А уж сколько чудовищ рождают программеры... особенно это касается пакетных манагеров редхата, кстати.Я не знаю где там у них разум был но вечными перетрясками своих пакетных манагеров они малость заколебали а rpm в его разных инкарнациях просто ужасен.Что тупорылая структура пакетов что сам манагер.Вот уж кого я не стал бы ставить как эталон в плане пакетных систем так это редхат.Они IMHO представляют из себя отличный пример того как делать НЕ НАДО!И они будут учить других делать пакетные манагеры?!Упаси боже от таких учителей :\


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено borey , 24-Июн-08 22:48 
Простите. Но разложите мне пожалуйста,как сей продукт использующего, по пунктам чем rpm так уж сильно отличается от deb к примеру.

"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено trey , 24-Июн-08 22:55 
>Простите. Но разложите мне пожалуйста,как сей продукт использующего, по пунктам чем rpm
>так уж сильно отличается от deb к примеру.

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


"*sigh*"
Отправлено Michael Shigorin , 25-Июн-08 01:52 
>Что тупорылая структура пакетов что сам манагер.

Уважаемый, Вас тупорыло несёт второе сообщение.

dpkg несколько лучше изначально спроектирован для универсальных применений (тыскыть научный подход), а rpm -- для прикладных (инженерный).  Это выливается в разные выборы в подобных ситуациях (например, штатность возможности интерактива при установке отдельного пакета).

А путать редхат, федору, RPM и .rpm в одну кашу в голове -- не следует.  При всей моей иронии относительно федоры-то.

2 trey: видите ли, убунтушники в массе своей отличаются не только повальным отсутствием сообразительности, но и тем, что их заразным образом несёт.  Вот и этого экземпляра пронесло, а кто-то ведь и купиться может.  Можно грохнуть, но бывает лучше объяснить, где неправ -- вдруг дойдёт.

2 blkdog: перевод во многих местах нелокализованный, сильно рекомендую по возможности почитать грамотно изданную литературу на аглицком (не рассылки).  E.g. "что не в этом случае" -- видимо, "это не так" (this is not the case).  Если хотите, можно попробовать порой в жабере помогать.


"*sigh*"
Отправлено User294 , 25-Июн-08 13:24 
>dpkg несколько лучше изначально спроектирован для универсальных применений (тыскыть научный подход), а
>rpm -- для прикладных (инженерный).  

Интересно, для каких прикладных задач придумывали RPM если на практике и в реальной жизни DEB удобнее?Я например оба пользовал и RPM (несколько разных версий в разных версиях CentOS) мне не понравились.

>А путать редхат, федору, RPM и .rpm в одну кашу в голове
>-- не следует.  При всей моей иронии относительно федоры-то.

Редхат эту заварушку и заварил.Развели зоопарк да еще постоянно все перетрясают, так что там черт ногу сломит.Почему-то debian based обходятся без такого жуткого бардака.Даже IT OS на Nokia n8x0 использует стандартный манагер пакетов хоть и с своей графической мордочкой к нему, но собственно все свойства дебиановского манагера пакетов - при нем.А консольный вариант вообще ничем таким от десктопных не отличается.Вопрос: кому и нафига при этом кроме редхата надо какое-то непонятное апи если и без него проблем особых нет?

>Вот и этого экземпляра пронесло, а кто-то ведь и купиться может.

Объясняю в чем у вас ошибка: вы выпускаете систему на основе этого ... добра.И потому во первых нечаянно и нисколько не задумываясь делаете им скидку.Сами того не подозревая скорее всего.Во вторых вы все это знаете на уровне гуру и вам кажется что все просто и понятно.Ваша ошибка типична.Не будут люди со стороны делать скидок редхату на их кривульки.И разбираться в всем этом бардаке большей части пользователей и админов обычно неохота.

> Можно грохнуть, но бывает лучше объяснить, где неправ -- вдруг
>дойдёт.

А вам можно сказать: у вас неплохая система.Но вот как раз базированность на редхате все портит.Если честно - простите но лично я например не верю в то что у вашей системы большое будущее.Как раз из-за основанности на редхате.Редхат что-то из себя представляет на энтерпрайз поприще а на остальные рынки даже всерьез и не пытается соваться, понимая что не переспективно это с тем что у них есть.Может конечно у вас что-то и получится.Тогда я за вас порадуюсь.Но сам я вашу систему юзал бы дома только если бы она была основана на дебиане или даже лучше (для домашнего использования) убунту.Может редхат и был хорош когда вы начинали делать вашу ос и был лучше других.А сейчас... сейчас редхат что-то из себя представляет только в энтерпрайз секторе.


"*sigh*"
Отправлено Michael Shigorin , 26-Июн-08 01:52 
>Интересно, для каких прикладных задач придумывали 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) и весьма впечатляющей разработки по их автоматическому обнаружению (как сборочных, так и установочных; как для бинарников, так и для скриптовых языков).

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

Это важно для качества пакетной базы.


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено kostbebix , 25-Июн-08 01:43 
>[оверквотинг удален]
>Если у редхата и федоры вечные грабли с софтом, они что, хотят
>чтобы другие за них решали их проблемы?Лично мне за глаза хватает
>.deb пакетов для убунты, как и для дебиана а dpkg показал
>себя достаточно адекватным и удобным пакетным манагером который тем не менее
>довольно сложно убить.Во всяком случае за 2 года юзания убить его
>не вышло.Было пару сбоев но он еще и подсказывает как чинить
>если из консоли пнуть :).Кроме того dpkg в отличие от некоторых
>других постепенно и плавно эволюционирует а не перекореживается каждый раз до
>неузнаваемости.И потому в отличие от редхата нет у других этих проблем.Ну
>вот они и не дергаются.

Подтвердите слова свои? Особенно про грабли в федоре с софтом)

>
>А вот редхату хочется сказать свое "фи" за то что они постоянно
>перекореживают свои пакетные манагеры.

К примеру когда они их перекореживали?

>Они хотят чтобы у всех было так же
>хреново как у них?Спасибо им большое... но у меня по этому
>поводу энтузазизма как раз тоже нет.Шли б они в ... с
>их иксэмэлками и дэбасами.Работает - не трожь!А то потом и у
>других будет такой же трах с постоянным освоением новых версий пакетных
>тулзов.Нафиг-нафиг...

Что вы знаете о deb и rpm?


"Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"
Отправлено Аноним , 24-Июн-08 16:25 
"Установка ПО в Linux - задача достаточно сложная и по большей части не может контролироваться даже самим пользователем системы."

Ха. Как хорощо узнать, что ты не единственный, кто видит кривизну. Осталось подождать пока заметное кол-во людей, наевшись кактусов, начнут спрашивать "а что ты там говорил про управление пакетами прикладного ПО".


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Анонимус , 24-Июн-08 22:21 
>Ха. Как хорощо узнать, что ты не единственный, кто видит кривизну. Осталось
>подождать пока заметное кол-во людей, наевшись кактусов, начнут спрашивать "а что
>ты там говорил про управление пакетами прикладного ПО".

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


"Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"
Отправлено anarsoul , 24-Июн-08 17:01 
> Установка ПО в Linux - задача достаточно сложная

Бред, чего сложного в пакетных менеджерах и их фронтендах? (Типа synaptic)
И с какой это стороны неуправляемо пользователем системы??


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Knuckles , 24-Июн-08 17:30 
Думаю, под неуправляемостью подразумевается тот факт, что после автомагического разрешения 10-20 зависимостей для пакета и установки нужной тебе софтины ты вряд ли вспомнишь, что еще нужно удалить вместе с этим пакетом, чтобы вернуть "все как было". И чтоб ничего не поломать. И чтоб быстро. А пакетов мноооого...
Я слышал, в последней мандриве пакетный менеджер будет определять, что пакет более не используется другими пакетами и предлагать его удаление. Не знаю, как там это будет работать, но грызут сомнения, что не идеально.

"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено anonymous , 24-Июн-08 17:59 
бгг, аптитуда уже давно умеет, причем по умолчанию.

да и пакман тоже.


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Аноним , 24-Июн-08 18:41 
но в apt сей функционал почему-то включать не хоят

"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено ewrw , 24-Июн-08 18:54 
>но в apt сей функционал почему-то включать не хоят

а что такое apt-get autoremove ?


"emerge рулит :)"
Отправлено himik , 24-Июн-08 23:59 
emerge в Gentoo по моему неплохо справляется с задачей кдаления неиспользуемых пакетов..

"Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"
Отправлено pavlinux , 24-Июн-08 17:11 
Он думал, - зачем ставить в RedHat, пакет от Ubuntu или от SuSE в Debian???

"Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"
Отправлено Дмитрий Ю. Карпов , 24-Июн-08 17:20 
Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать её в Linux. Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии, мир скоро перейдёт на FreeBSD.

"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Аноним , 24-Июн-08 17:24 
>мир скоро перейдёт на FreeBSD.

Не перейдёт, потому что есть ArchLinux, вобравший в себя самые лучшие особенности FreeBSD


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено tux2002 , 25-Июн-08 08:42 
>>мир скоро перейдёт на FreeBSD.
>
>Не перейдёт, потому что есть ArchLinux, вобравший в себя самые лучшие особенности
>FreeBSD

Slackware тоже нормально.


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Аноним , 24-Июн-08 17:27 
ИМХО там совсем нет системы этих самых пакаджей. Есть система портов, а это вовсе не одно и то же.

"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено anonymous , 24-Июн-08 17:42 
Давно портировали, Gentoo называется. И удаление неиспользуемых пакетов работает.

"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено .3 , 24-Июн-08 19:35 
>Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать
>её в Linux. Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии,
>мир скоро перейдёт на FreeBSD.

Ничего хуже системы портов FreeBSD я не знаю. Простая задача: есть самописная софтина, она зависит, ну, например, от стандартного sqlite (не важно). Расскажите, как же мне поставить мою софтину хотя бы на 20 серверов.


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Guest , 24-Июн-08 22:17 
Пожалуйста, 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

Для деплоя как раз лучше портов ничего не придумали.


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено .3 , 24-Июн-08 22:40 
А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты (и их синхронизировать каждый день)? И я еще молчу про то, что библиотеки изредка меняются в пределах одной major.minor версии. И проверить это можно только с помощью getosreldate (здравствуй, статическая линковка!).

Собирать на продакшен машинах, конечно, смешная идея, но в некоторых случаях это возможно. Но то, что это будет проходить под рутом (да, я знаю про fakeroot), уже нехорошо.

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

Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом. Но сейчас остальные системы куда совершенее.


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Guest , 25-Июн-08 01:05 
> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты (и их синхронизировать каждый день)?

Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред?

> Собирать на продакшен машинах, конечно, смешная идея

Ничего смешного. Там что, компилятора нет? Или может процессор 486?

> но в некоторых случаях это возможно. Но то, что это будет проходить под рутом (да, я знаю про fakeroot), уже нехорошо.

А вам что там, надо неизвестно чей софт собирать? Тогда пакаджи, все абсолютно аналогично портам.

> В случае же, когда программа постоянно меняется, а выкатывается раз в месяц, иногда реже, сборка может продолжаться очень долго. На продакшене. Ага.

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

> Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом. Но сейчас остальные системы куда совершенее.

Да что вы?


"*sigh*"
Отправлено Michael Shigorin , 25-Июн-08 02:11 
Нет, ну это просто феерическое нечто.

>> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты
>> (и их синхронизировать каждый день)?
>Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред?

Вы всерьёз предлагаете каждый раз собирать?  Никогда не слышали про "воспроизводимость сборки" случайно?  Что вообще-то код, собранный на одной машине -- может работать на тысячах совершенно других и при этом отладка стека ПО на любой физически исправной из них будет эквивалентна, а не уникальна по надцати параметрам?

>> Собирать на продакшен машинах, конечно, смешная идея
>Ничего смешного. Там что, компилятора нет? Или может процессор 486?

Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?  Может, ещё самолёты в рейсе модернизировать?

>Телепаты в отпуске, угадывать какие у вас там продакшны и какие программы.

Телепатов у вас там явно нет вообще, так что не надо про отпуск.  Гадать тоже не умеете: где продакшен, там очень сильно помогает от головной боли воспроизводимость.  А с source-based это свойство не дружит, только с package-based при условии наличия сборочной технологии, включающей создание изолированной воспроизводимой среды сборки и возможности фиксации состояния пакетной базы для этой самой воспроизводимости.

>Собирается долго - ставьте кластер и собирайте на нем.

Под рукой есть три кластера, а вот идиотов, чтобы "собирать на нём" (для чего -- для каждой ноды?  или сэр даже слышал про distcc?) -- пока не нашлось.

Так что совет того, бесплатный.

>> Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом.
>> Но сейчас остальные системы куда совершенее.
>Да что вы?

Выдыхай, бобёр.  Выдыхай.  Только осторожно, скрытая камера фиксирует для истории.

Я вот этот образчик так отложу себе в тематическую коллекцию шедевров.


"*sigh*"
Отправлено oops , 25-Июн-08 06:54 
>[оверквотинг удален]
>
>>> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты
>>> (и их синхронизировать каждый день)?
>>Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред?
>
>Вы всерьёз предлагаете каждый раз собирать?  Никогда не слышали про "воспроизводимость
>сборки" случайно?  Что вообще-то код, собранный на одной машине --
>может работать на тысячах совершенно других и при этом отладка стека
>ПО на любой физически исправной из них будет эквивалентна, а не
>уникальна по надцати параметрам?

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

>>> Собирать на продакшен машинах, конечно, смешная идея
>>Ничего смешного. Там что, компилятора нет? Или может процессор 486?
>Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?  Может,
>ещё самолёты в рейсе модернизировать?

Вы давно видели фряху? Там компилятор идет из коробки и всегда присутствует в системе.

>>Телепаты в отпуске, угадывать какие у вас там продакшны и какие программы.
>Телепатов у вас там явно нет вообще, так что не надо про
>отпуск.  Гадать тоже не умеете: где продакшен, там очень сильно
>помогает от головной боли воспроизводимость.  А с source-based это свойство
>не дружит, только с package-based при условии наличия сборочной технологии, включающей
>создание изолированной воспроизводимой среды сборки и возможности фиксации состояния пакетной базы
>для этой самой воспроизводимости.

Фиксируйте на здоровье. Поставьте машинку для этих целей или jail поднимите. Там хоть зафиксируйтесь. Создать собственный пакетный репозиторий времени занимает не так много, и делается один раз.

>>Собирается долго - ставьте кластер и собирайте на нем.
>Под рукой есть три кластера, а вот идиотов, чтобы "собирать на нём"
>(для чего -- для каждой ноды?  или сэр даже слышал
>про distcc?) -- пока не нашлось.

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

>Так что совет того, бесплатный.
>>> Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом.
>>> Но сейчас остальные системы куда совершенее.
>>Да что вы?
>Выдыхай, бобёр.  Выдыхай.  Только осторожно, скрытая камера фиксирует для истории.
>Я вот этот образчик так отложу себе в тематическую коллекцию шедевров.

Отложите и подумайте где вы не правы.


"*sigh*"
Отправлено Michael Shigorin , 26-Июн-08 02:15 
>>>> Собирать на продакшен машинах, конечно, смешная идея
>>>Ничего смешного. Там что, компилятора нет? Или может процессор 486?
>>Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?  Может,
>>ещё самолёты в рейсе модернизировать?
>Вы давно видели фряху?

Недавно последнюю четвёрку хоронил, где был логин, а что?

>Там компилятор идет из коробки и всегда присутствует в системе.

То-то и оно.  Могу ещё раз повторить своё утверждение:
"Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?"

Впрочем, фрю к продакшен-системам не отношу по ещё более веским причинам, чем компилятор в basesystem -- чуть выше повторялся про бранчи портов.

>Поставьте машинку для этих целей или jail поднимите.

Спасибо, я вчера походя склонировал два и перенёс ещё два контейнера (на поднятые в т.ч. для них машинки).

>Создать собственный пакетный репозиторий времени занимает не так много,
>и делается один раз.

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

Давайте лучше соглашусь с этими Вашими словами, чем буду развивать тему про репо? :)
> За сборку и тесты на продакшне надо отрывать руки.
> За апгрейд без обкатки на тестовой машине - голову.

Только вот ведь какая штука -- инструментально очерченный процесс гораздо более проработан на пакетных линуксах.  Бишь вероятность ошибиться неочевидным образом на порядки меньше.

>>Я вот этот образчик так отложу себе в тематическую коллекцию шедевров.
>Отложите и подумайте где вы не правы.

Это было сделано в процессе перечитывания перед отправкой.
Как видите, и то отправил, и это.

Поясните?


"*sigh*"
Отправлено oops , 26-Июн-08 06:41 
>>Вы давно видели фряху?
>Недавно последнюю четвёрку хоронил, где был логин, а что?

Значит давно.

>>Там компилятор идет из коробки и всегда присутствует в системе.
>То-то и оно.  Могу ещё раз повторить своё утверждение:
>"Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?"

Вам компилятор жить мешает? Ну так на то и 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", часто не понимая как она живет в реальных условиях и что с ней делать. Я вижу это каждый день.


"*sigh*"
Отправлено pavel_simple , 26-Июн-08 08:20 
> Я вижу это каждый
>день.

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

P.S. И Вы не поверите.... -- "всё правильно сделал!" (C) Какая-то там страховая компания.


"*sigh*"
Отправлено Michael Shigorin , 26-Июн-08 16:57 
>>>Вы давно видели фряху?
>>Недавно последнюю четвёрку хоронил, где был логин, а что?
>Значит давно.

К сожалению, в контексте обсуждаемого вопроса та поросшая мхом немигрируемая 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"...

Спорить с умными людьми полезно тем, что узнаёшь что-то новое и излагая то, что знаешь -- находишь в нём неожиданные грани.

Потому на это время и находится порой. :-)


"*sigh*"
Отправлено Guest , 25-Июн-08 20:27 
Три кластера под рукой.. Почему сразу не десять?

Боже, даже комментировать не хочу. Дешевый непрофессиональный троллинг.


"*sigh*"
Отправлено Michael Shigorin , 26-Июн-08 02:25 
>Три кластера под рукой.. Почему сразу не десять?

Потому что СКИТ-1, СКИТ-2, СКИТ-3 -- это три кластера, а не десять.  На КПИ-шный не ходок.

>Боже, даже комментировать не хочу. Дешевый непрофессиональный троллинг.

Ну так и не занимайтесь им, или тоже квалифицируйтесь на нормального тролля :-)

http://icybcluster.org.ua/

[XXXX@ZZZZ ~]$ squeue | awk '{print $2;}' | sort -u
PARTITION
scit1
scit2
scit3

На scit3 вон коллега данные для автоматического переводчика обрабатывает :-)

$ squeue | grep pere | wc -l          
15

60 ядер и 120Gb RAM куда быстрей приводят к появлению и улучшению языковых пар, чем домашняя машинка...


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено .3 , 25-Июн-08 10:38 
>> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты (и их синхронизировать каждый день)?
> Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред?

А pkg_add -r уже научился ходить по разным серверам?

>> Собирать на продакшен машинах, конечно, смешная идея
> Ничего смешного. Там что, компилятора нет? Или может процессор 486?

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

И, прошу обратить внимание, не надо быть телепатом, что бы это знать.

> Собирается долго - ставьте кластер и собирайте на нем.

Если собирать на кластере, то, наверное потом это надо будет принести с кластера, или во фре уже есть libastral?


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Осторожный , 25-Июн-08 10:55 
>>> А ничего, что в случае 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


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено .3 , 25-Июн-08 11:44 
>[оверквотинг удален]
>
>Вообще-то всегда умел :)
>
>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

Я тут вижу только один сервер.


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Осторожный , 25-Июн-08 10:59 
>>> Собирать на продакшен машинах, конечно, смешная идея
>> Ничего смешного. Там что, компилятора нет? Или может процессор 486?
>
>А то, что машина может быть загружена своей основной работой --- это
>ничего? После сборки надо прогнать тесты, или где--то не так? У
>тестов (да и у сборки) может быть еще одна большая куча
>зависимостей. И ее тоже надо будет поставить на продакшен. И следить
>за версиями.

1) Выделяется отдельный сервер
2) На нем синхронизуются порты
3) Делается сборка нужных портов с помощью portupgrade
   Включая свою софтину
4) На этом же сервере можно делать тесты
5) Когда убедились что все работает, тогда ставим на production
   Хотя вообще по-хорошему тесты надо делать еще когда пишется софтина :)
   mount /usr/ports
   portupgrade -aPPR my_program
   umount /usr/ports


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено .3 , 25-Июн-08 14:18 
> Хотя вообще по-хорошему тесты надо делать еще когда пишется софтина :)

На некоторые тесты уходят часы.

>   mount /usr/ports
>   portupgrade -aPPR my_program
>   umount /usr/ports

Не правда ли проще подключить репозаторий, а потом сказать apt-get/yum?


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено oops , 25-Июн-08 13:28 
>>> Собирать на продакшен машинах, конечно, смешная идея
>> Ничего смешного. Там что, компилятора нет? Или может процессор 486?
>А то, что машина может быть загружена своей основной работой --- это
>ничего? После сборки надо прогнать тесты, или где--то не так? У
>тестов (да и у сборки) может быть еще одна большая куча
>зависимостей. И ее тоже надо будет поставить на продакшен. И следить
>за версиями.
>И, прошу обратить внимание, не надо быть телепатом, что бы это знать.

За сборку и тесты на продакшне надо отрывать руки.
За апгрейд без обкатки на тестовой машине - голову.



"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено .3 , 25-Июн-08 14:11 
>За сборку и тесты на продакшне надо отрывать руки.
>За апгрейд без обкатки на тестовой машине - голову.

Мне это говорить не надо. Говорите это Guest'у, который не видит в этом ничего странного.


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Guest , 25-Июн-08 20:29 
> Говорите это Guest'у, который не видит в этом ничего странного.

Из каких же моих слов вы сделали такой вывод?


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено .3 , 26-Июн-08 00:25 
>> Говорите это Guest'у, который не видит в этом ничего странного.
>
>Из каких же моих слов вы сделали такой вывод?

Сообщение #42, цитата:
> Собирать на продакшен машинах, конечно, смешная идея

Ничего смешного. Там что, компилятора нет? Или может процессор 486?


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено fi , 26-Июн-08 00:37 
> За сборку и тесты на продакшне надо отрывать руки.
> За апгрейд без обкатки на тестовой машине - голову.

Этого мало!!! Лучше начинать с яиц -  безболезненней будет

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

PS за что и признаны пакетные системы - софт уже идет протестенный. что конечно не отменяет обкатки.


"gcc  wget"
Отправлено Michael Shigorin , 26-Июн-08 17:18 
>Да и сам компилятор лучше удалить с продакшин - большенство локальных уязвимостей
>требуют его.

Вообще-то нет (и по словам опять же людей, которым склонен верить -- сейчас в основном молодёжь со своими бинарниками шарится), но рассматривание ряда .bash_history наводит на мысль, что мера предосторожности всё равно не лишняя.

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

BTW дочитавшим досюда маленький бонус: http://sisyphus.ru/srpm/apache-honeypot


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено kostbebix , 24-Июн-08 20:20 
Кхм кхм. Совершенно недавно на работе я таки добился установки bugzilla. На сервак с freebsd - пишу фигню с портом (спасибо сисадмину, помог строчкой) - установило, сиди и пили сколько угодно дальше, потом еще пилил... Установил. Почти. Заняло ~2 часа, должно работать, но там какая-то фигня с сэндмэйлом, которая так и не заработала (лень разбираться).

Попробовал на Gentoo. Тоже. Из портов сначала не собралось, потом где-то чего-то подпилили, собралось. Пилил пилил - та же фигня что и во фре с сэндмэйлом. Снова лень разбираться (в генте тоже никогда ничего не делал, да и сервак не мой, экспериментировать сильно не хотел).

Ради чистоты эксперимента попробовал у себя под федорой.
yum -y install bugzilla
а далее - создать пользователя bugs и запустить скрипт багзилловский.


Сорри что много текста лишнего, просто наболело. Я к чему это все - в портах минус: не всегда оно собирается, надо чего-то делать еще. В rpm и deb'ах все куда вероятнее что заработает с полупинка (по крайней мере у меня так).


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено oops , 25-Июн-08 06:58 
>Кхм кхм. Совершенно недавно на работе я таки добился установки bugzilla. На
>сервак с freebsd - пишу фигню с портом (спасибо сисадмину, помог
>строчкой) - установило, сиди и пили сколько угодно дальше, потом еще
>пилил... Установил. Почти. Заняло ~2 часа, должно работать, но там какая-то
>фигня с сэндмэйлом, которая так и не заработала (лень разбираться).

pkg_add -r <pkgname> или portupgrade -PP <origin>
с сэндмейлом надо понимать на месте. или отключить его и поставить MTA который вы знаете.


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено kostbebix , 25-Июн-08 11:25 
>>Кхм кхм. Совершенно недавно на работе я таки добился установки bugzilla. На
>>сервак с freebsd - пишу фигню с портом (спасибо сисадмину, помог
>>строчкой) - установило, сиди и пили сколько угодно дальше, потом еще
>>пилил... Установил. Почти. Заняло ~2 часа, должно работать, но там какая-то
>>фигня с сэндмэйлом, которая так и не заработала (лень разбираться).
>
>pkg_add -r <pkgname> или portupgrade -PP <origin>
>с сэндмейлом надо понимать на месте. или отключить его и поставить MTA
>который вы знаете.

Ну там основное время ушло на сборку модулей перла (руками надо было каждую прописывать, а потом, по идее, отвечать на кучу вопросов, но я делал yes2all, и все равно не все установилось). В федоре (в той же) оно сделано иначе. На примере пхп:

чтоб проинсталлировать пхп надо сделать
yum install php

Чтобы подключить поддержку mysql не надо ничего пересобирать или еще чего. Достаточно сделать
yum install php-mysql

Так же и с перлом и остальными.


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено oops , 25-Июн-08 13:07 
>Ну там основное время ушло на сборку модулей перла (руками надо было
>каждую прописывать, а потом, по идее, отвечать на кучу вопросов, но
>я делал yes2all, и все равно не все установилось).

Случайно не через cpan ставились?

>Чтобы подключить поддержку mysql не надо ничего пересобирать или еще чего. Достаточно
>сделать
>yum install php-mysql
>
>Так же и с перлом и остальными.

Чем это сложнее pkg_add -r или portupgrade -PP? оба варианта поставят исключительно бинарный пакет безо всяких пересборок и приплясываний..


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено kostbebix , 26-Июн-08 11:07 
>Случайно не через cpan ставились?

Да, он.

>Чем это сложнее pkg_add -r или portupgrade -PP? оба варианта поставят исключительно
>бинарный пакет безо всяких пересборок и приплясываний..

Типа установлен php, не надо его пересобирать с флагом --with-gd (к примеру), а можно сделать что-то вроде yum install php-gd2? типа pkg_add -r php-gd2? (чисто интуитивно)


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено oops , 26-Июн-08 13:27 
>>Случайно не через 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 нужно знать точное имя пакета. можно посмотреть в порту.


"Решит ли?! :-D"
Отправлено Andrey Mitrofanov , 26-Июн-08 13:31 
>>а можно сделать что-то вроде yum install php-gd2? типа pkg_add -r
>>php-gd2? (чисто интуитивно)
>portupgrade -PP graphics/php5-gd (или graphics/php4-gd)
>Для pkg_add нужно знать точное имя пакета. можно посмотреть в порту.

...что снова возвращает нас к вопросу, "Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"?? :-))))


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Guest , 24-Июн-08 22:47 
> Мне кажется весьма удобной система пакаджей во FreeBSD

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

> пора бы портировать её в Linux

Гентушный portage в некотором смысле аналог, хотя у него есть смои большие плюсы и большие минусы
pkgsrc можно использовать вообще почти везде, от linux до solaris, он к портам гораздо ближе.

Вообще дело не в этом. Дело в том имхо, что любая система пакетов должна основываться на исходниках, но при этом уметь порождать самодостаточные бинарные пакеты. Это значит, что не maintainer'ы не собирают пакеты как хотят, а пишут инструкцию, как пакет собрать (аналог порта FreeBSD или ebuild'а), после чего добавляют ее в репозиторий. Заодно могут залить и сам пакет, по ней собранный.

Итого: имеем все плюсы source-based систем. Автоматизированная проверка и сборка подо все архитектуры, возможность быстро обновить порт до новой версии (просто взяв существующий и изменив циферку) и т.д. В то же время из этого должны получаться пакеты, которые как минимум знают, с какими версиями зависимых пакетов они могут работать. FreeBSD'шные пакаджи, например, не знают. Будут писать ворнинги, если версии не совпадают, и если, например, shared lib версия поменялась или еще какой косяк, ничего сделать не cмогут.
Ну и системная библиотека для управления этим всем, чтобы любой пакет можно было установить одной командой, причем установка из исходников/бинарников меняется одним ключиком.

Короче, потенциально есть куда развиваться всем существующим пакетным менеджерам, но то, что `Установка ПО в Linux - задача достаточно сложная', и идеи о новом API, основанном на D-BUS (!!!) и XML - такой концентрированный параноидальный бред, что мне даже страшно.


"какие пакаджи..."
Отправлено Michael Shigorin , 25-Июн-08 02:00 
>Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать
>её в Linux.

Дмитрий, от Вас не ожидал.

Во-первых, пакетные системы в линуксах -- как минимум apt -- на порядок более развиты, чем зачаточная пакетная система FreeBSD.  Можете поискать да хотя бы и в архивах r.o.c разборы полётов :-)

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

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

Когда кажется -- креститься пора :-)

>Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии,
>мир скоро перейдёт на FreeBSD.

Бздюшники пытались жёстко гнобить тех, кто нарушил даже не текст их лицензии, а то, что они себе возомнили.  Всё равно за бортом.

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


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено oops , 25-Июн-08 06:41 
>Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать
>её в Linux. Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии,
>мир скоро перейдёт на FreeBSD.

Система пакаджей во фряхе довольно убога:
1. Пакетная база - набор каталогов с информацией о структуре и содержимом пакета. На большом количестве установленного софта начинаются заметные тормоза, так как упираемся в дисковую подсистему.
2. Жесткие зависимости. т.е. при обновлении пакета на который ссылается другой пакет получаем битую зависимость.
3. Отсутствие апгрейда как такового.

Система портов тоже не без недостатков. В частности:
1. Приходится долго и аккуратно подгонять make.conf под свои нужды, чтобы собраться скажем именно с апачем версии 2.0 и с нужными опциями, которые не всегда можно получить по make config(но присутствуют в Makefile порта).
2. Зачастую невозможно собрать два пакета с разными опциями с одного порта и сложить в один пакетный репозиторий, т.к. имена таких пакетов вероятнее всего совпадут. Бывают правда и исключения например для опции WITH_THREADS.
3. Апгрейд никакой.

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


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено oops , 25-Июн-08 07:04 
Из плюсов могу отметить гибкость портовой системы и _предсказуемость_ поведения как портов так и пакетов. Для админа эти плюсы легко перевешивают все минусы перечисленные выше.

"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Осторожный , 25-Июн-08 11:25 
>Система пакаджей во фряхе довольно убога:
>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 хорошая вещь, но все равно не решает всех проблем.


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено oops , 25-Июн-08 13:22 
>[оверквотинг удален]
>>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 хорошая вещь, но все равно не решает всех проблем.

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



"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено .3 , 25-Июн-08 14:21 
> Получить битую зависимость можно если удалить пакет с ключом "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


"Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"
Отправлено Аноним , 24-Июн-08 17:27 
Зачем создавать ещё одну прослойку для линукса, и без того проблем хватает. Самая лучшая (но конечно не самая удобная и простая) установка пакетов реализована в slackware. Это предел простоты, и вот это должно быть примером для всех создателей дистрибутивов.

"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Knuckles , 24-Июн-08 17:33 
Не самая лучшая. Недавно решил удалить ненужные пакеты и понял, что не знаю, как.
Ну покоцал, конечно, те, которые знаю, что точно не нужны. А сколько осталось lib*super-puper*.tgz и представить боюсь :)

"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено tux2002 , 25-Июн-08 09:18 
>Не самая лучшая. Недавно решил удалить ненужные пакеты и понял, что не
>знаю, как.
>Ну покоцал, конечно, те, которые знаю, что точно не нужны. А сколько
>осталось lib*super-puper*.tgz и представить боюсь :)

Если ставишь через пакет, то и удаляешь removepkg. А то что make install DESTDIR= и затем makepkg это уж каждый кто устанавливает slackware должен знать сразу.



"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено tux2002 , 25-Июн-08 09:20 
>>Не самая лучшая. Недавно решил удалить ненужные пакеты и понял, что не
>>знаю, как.
>>Ну покоцал, конечно, те, которые знаю, что точно не нужны. А сколько
>>осталось lib*super-puper*.tgz и представить боюсь :)

Ктому же есть /var/adm/packages



"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Knuckles , 25-Июн-08 09:27 
Спасибо, как устанавливать и удалять пакеты я сам знаю :)
Речь о другом:
http://www.opennet.me/openforum/vsluhforumID3/42532.html#10

"слакваристы"
Отправлено Michael Shigorin , 26-Июн-08 02:29 
> это уж каждый кто устанавливает slackware должен знать сразу.

Видите ли, те деятели, которые бегают и орут "слакарулит", это не склонны своим доверчивым жертвам рассказывать.

Почему бы последние были "должны"?  Если я кому-то что-то впариваю, так это _я должен_ рассказать про подводные грабли, а не человек -- догадываться или впитать с молоком матери.

Следствие: не утруждаетесь рассказывать -- не впаривайте, имейте совесть.


"ух ты, слакварист 8)"
Отправлено Michael Shigorin , 25-Июн-08 02:19 
>Зачем создавать ещё одну прослойку для линукса, и без того проблем хватает.

[*]

>Самая лучшая (но конечно не самая удобная и простая)

А чем лучшая-то?  Она ведь ещё и не самая надёжная.

>установка пакетов реализована в slackware. Это предел простоты

Не простоты, а примитивности.

>и вот это должно быть примером для всех создателей дистрибутивов.

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

Для начала предлагаю http://lafox.net/support/index.php?showtopic=11769


"ух ты, слакварист 8)"
Отправлено tux2002 , 26-Июн-08 11:07 

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

Вы дистрибутивы без обратной связи с конечными пользователями делаете? Может быть убогие пользователи чего и подсказали бы :). Насчёт slackware - мне хватает её уровня сложности (если хотите примитивности). Изучать что-то ещё мне нехватает времени. Пусть например CentOS хороший дистрибутив, но я не собираюсь мёрзнуть в серверной управляя через графику (вообще X на серверах не держим), или растаскивать симлинки в rc.d вручную. Возьмём примитивнейший пример настройки сетевого интерфейса. Я знаю где лежит конфигурационный файл, но он пуст. Крутые дистростроители забыли предложить шаблон  хотя бы в виде комментариев. Я что должен из-за такой фигни хэндбуки курить? Так что почаще с пользователями советуйтесь.


"'хэндбуки' и 'с пользователями'"
Отправлено Michael Shigorin , 26-Июн-08 17:35 
>>Вы мож сперва проблемы, которых хватает, порешайте?  А потом нам, убогим
>>создателям дистрибутивов, придёте и расскажете чего-нить умного.
>Вы дистрибутивы без обратной связи с конечными пользователями делаете?

Ну почему же.  Отвечать могу только за себя -- стараюсь слушать, хотя тоже порой в своп ухожу :)

>Может быть убогие пользователи чего и подсказали бы :)

У нас обычно очень даже ничего пользователи, иной раз интереснейшие вещи рассказывают ;)

>Насчёт 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 стараюсь делать так, чтоб было удобно и полезно себе и другим.  И это скорее правило по команде (хотя бывают заскоки, конечно).


"'хэндбуки' и 'с пользователями'"
Отправлено tux2002 , 26-Июн-08 18:29 

>Подсказать, почему не хватает, или сами догадаетесь?  Попробуйте сопоставить время на
>решение задачи и время на возню с системой, не направленное непосредственно
>на решение этой самой задачи.
>Давайте посоветуемся.  Только сразу предупреждаю, к CentOS/RHEL у меня отношение тоже
>ироничное, хоть и по другим поводам :-)  А в ALT
>стараюсь делать так, чтоб было удобно и полезно себе и другим.
> И это скорее правило по команде (хотя бывают заскоки, конечно).
>

Давайте посоветуемся и про затраченное время.

ALT не видел, говорят хороший дистрибутив, посмотрю в ближайшее время. Загрузчик надеюсь предлагается запаролить при установке? Интересно как там у Вас со сборкой например зависимостей glibc->samba скажем с march=nocona.



"буки' и 'с пользоват"
Отправлено Andrey Mitrofanov , 26-Июн-08 18:38 
>ALT не видел, говорят хороший дистрибутив

[...]
>Интересно как там у Вас со сборкой например

[...]
>скажем с march=nocona.

:-O То есть _не_ сорс-бейзеd дистрибутивов Вы вообще не видели? Мама-мама-мама...


"буки' и 'с пользоват"
Отправлено tux2002 , 26-Июн-08 18:56 

>:-O То есть _не_ сорс-бейзеd дистрибутивов Вы вообще не видели? Мама-мама-мама...

А что мне march=i486 mtune=i686 на сервер что ли ставить где 300 пользователей файлы гоняют самбой чараз кламав, да ещё жестоко VSS? Видел, на ноуте неплохо смотрятся.


"'хэндбуки' и 'с пользователями'"
Отправлено Michael Shigorin , 26-Июн-08 19:47 
>Давайте посоветуемся и про затраченное время

/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 -- проблемы последнее время бывали разве что вида "Саша медлит с релизом-с-буковкой, говоря, что там ещё сейчас патчик будет" :-)


"Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"
Отправлено idkfa , 24-Июн-08 17:56 
лучше всего в solaris :)
никаких менеджеров - голова, блокнот и прямые руки :D

"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено anonymous , 25-Июн-08 00:19 
> лучше всего в solaris :)
> никаких менеджеров - голова, блокнот и прямые руки :D

+1; Очень просто, не отягощено гипертрофированными зависимостями
(и, когда я с ним работал, никаких навязчивых update'ов,
приводящих систему с публичными сервисами в непредсказуемое
состояние).


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Michael Shigorin , 25-Июн-08 02:21 
>> лучше всего в solaris :)
>> никаких менеджеров - голова, блокнот и прямые руки :D

Это простое человеческое щастье доступно пожалуй что на любом unix-like ;)  чем лучше-то?

>+1; Очень просто, не отягощено гипертрофированными зависимостями

Не переживайте, солярку уже пытаются привести в вид, приличный современному линуксу ;)


"Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"
Отправлено coder , 24-Июн-08 21:01 
Вряд ли это что-то решит. У Линуха должен быть свой собственный API для установки ПО. Иначе все поставщики его дистрибутивов так и будут продолжать лепить свои установщики

"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено xcode , 24-Июн-08 21:31 
>Вряд ли это что-то решит. У Линуха должен быть свой собственный API
>для установки ПО.

Если в итоге получится такое же глюкавое говнище как MSI инсталлер которое встает колом на каждый пшик, почти нихрена не умеет (кроме как глючить) и с массой ограничений - не, нафиг-нафиг.Линукс хорош выбором и тем что в итоге можно выбрать и что-то стоящее и нужное именно мне и именно в конкретно моих задачах порой.Вы такие умные?А покажите какую-нить систему под которую софта больше чем под .deb и .rpm?Всего 2 манагера пакетов кстати.


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено oops , 25-Июн-08 07:07 
>Если в итоге получится такое же глюкавое говнище как MSI инсталлер которое
>встает колом на каждый пшик, почти нихрена не умеет (кроме как
>глючить) и с массой ограничений - не, нафиг-нафиг.Линукс хорош выбором и
>тем что в итоге можно выбрать и что-то стоящее и нужное
>именно мне и именно в конкретно моих задачах порой.

Может говнище и глюкавое, но от транзакций на unix like осях лично я бы не отказался.


"транзакции"
Отправлено Michael Shigorin , 26-Июн-08 02:36 
>от транзакций на unix like осях лично я бы не отказался.

Для меня apt+rpm обеспечивают два уровня:

- rpm умеет обломить транзакцию в несколько пакетов вплоть до момента проверки на пересечение устанавливаемых/обновляемых пакетов на пересечения по файлам;
- rpm умеет обломить (откатить) установку одного пакета, если вдруг упёрлись в место/квоту/бэд/битый пакет (бишь он сперва распаковывает в файлы со случайными суффиксами и только если всё распаковалось -- unlink() старое);
- apt умеет обломить транзакцию по куче условий верхнего уровня (например, исчезновение нужного какому из пакетов soname из системы);
- apt умеет откатываться на пакеты с определёнными свойствами (pin-priority) -- впрочем, этим пользовался очень давно и нечасто, как-то не привык.

Как с первыми двумя пунктами у dpkg -- не доводилось выяснять (это всё-таки редкие случаи), но можно предположить, что где-то сопоставимо.

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


"транзакции"
Отправлено oops , 26-Июн-08 06:51 
>Вот с откатом действий, производимых пакетными скриптами, может быть полный нетривиал.  
>В смысле чтение их глазами да соображание, что было и что
>стало

в этом и заключается основная проблема. Как быть если я хочу поставить несколько пакетов в одной "транзакции"? при обломе я хочу откатиться на состояние до начала установки/апгрейда..



"транзакции"
Отправлено Michael Shigorin , 26-Июн-08 19:03 
>>Вот с откатом действий, производимых пакетными скриптами, может быть полный нетривиал.  
>>В смысле чтение их глазами да соображание, что было и что стало
>в этом и заключается основная проблема.

Вопрос, как обычно -- в том, какая именно проблема стоит и сколько готовности её решать.

>Как быть если я хочу поставить несколько пакетов в одной "транзакции"?

См. выше, тут это выходит в основном к apt и отчасти к rpm (насчёт пересечений).

>при обломе я хочу откатиться на состояние до начала установки/апгрейда..

Облом бывает разноплановый: одно дело откатить версии пакетов (это элементарно), другое -- например, "провернуть назад" фарш обновлённой базы данных после пинка в ребилдилку из постустановочного скрипта.  Или вот ещё один из частных примеров: https://bugzilla.altlinux.org/show_bug.cgi?id=14917 (rpm умеет после транзакции выполнить предварительно заданный код -- например, перестройку собственной базы; это и имелось в виду под post mortem).


Бишь задача поиска обратной функции к произвольной (а именно к ней сводится вопрос отката действий скриптов) -- боюсь, нерешаемая "в лоб".

В более-менее общем случае при условии пренебрежимости в разнице по остальному находящемуся на той же ФС состоянию[*]... наверное, я бы копал в сторону XFS/LVM snapshots.

* бишь пользователи или там базы могут и должны жить на других ФС, нежели пакетное ПО,
  если уж актуальна такая точность/гарантированность отката состояния

Но до сих пор хватало даже не аптовых pin'ов, а rpm -Uvh --oldpackage, благо случаи редки и происходят там, где и ожидаются (в основном unstable на буке).

Кстати, на практике с этим тоже контейнеры помогают: делаешь клон, изучаешь процесс в деталях, но без риска уронить production, и если всё устраивает -- можно перекинуть адреса и оставить старую VE-шку в качестве бэкапа, пока пыль точно не осядет.


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено anonymous , 25-Июн-08 00:28 
> Вряд ли это что-то решит. У Линуха должен быть свой собственный API для установки ПО.
> Иначе все поставщики его дистрибутивов так и будут продолжать лепить свои установщики

Есть мнение, что <<ужасное>> состояние инсталляции под Linux не идёт ни в какое сравнение с инсталляцией на W. С _любым_ PM (или без него) я способен найти приемлемый для меня use-case. Количество вариантов-кандидатов всегда > 1.


"Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"
Отправлено Guest , 24-Июн-08 22:28 
> Установка ПО в Linux - задача достаточно сложная и по большей части не может контролироваться даже самим пользователем системы.

Черт возьми. Ну доколе?! Откуда берутся эти идиоты и откуда они берут такие сложности?

- Линукс для дома - ubuntu. Synaptic - любой пакет ищется, скачивается и устанавливается/обновляется со всем зависимостями в пару кликов. Либо одной командой apt для которой надо помнить только 3 флага.

- Не десктопная FreeBSD. Любой порт ищется, устанавливается, скачивается/обновляется также одной командой, либо также одним кликом через GUI к портам (забыл уже как оно зовется).

В gentoo все ничем не сложнее, и подозреваю что в остальных mainstream дистрибутивах тоже. Бывшие Windows пользователи ОХРЕНЕВАЮТ, что ВЕСЬ софт ставится единообразно и мгновенно, и, при этом чисто потом удаляется.

Так нет, обязательно вылезет чудо, которое придумает свой суперпростой формат пакетов. Хорошим тоном у них еще считается все зависимости статически прилинковать, ага. Ну и найдется еще пачка странных людей, которые им поддакнут (см. посты #17 и #20). `Да-да, скажут, Linux для гиков, на любой чих ./configure надо и ядро пересобрать'.

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


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Michael Shigorin , 25-Июн-08 02:26 
>Так нет, обязательно вылезет чудо, которое придумает свой суперпростой формат пакетов.

Не просто суперпростой, а особенно суперпростой с XML и бантиками.

>Хорошим тоном у них еще считается все зависимости статически прилинковать, ага.

Ну эт скорее у слакваристов навроде rоdlinuх.

Вообще же тем, для кого synaptic сложен -- в новом распрекрасном мире показаны Wii/Xbox/PS3, мобила и тырнет-таблетка.  И никаких универсальных программируемых расширяемых компьютеров.


"Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"
Отправлено Аноним , 25-Июн-08 09:20 
Появится еще один бажный линуксовый пакет. Мне так линукс давно интересен только как встраиваемая система, в пользовательскую десктоп систему, я считаю, он не вырастет никогда. Ну а если ты например ставишь систему на какой-нить Colibri PXA и еще не врубился как собрать и проинсталить пакет, то тут уж ничего не поможет.

"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено kostbebix , 25-Июн-08 11:31 
>Появится еще один бажный линуксовый пакет. Мне так линукс давно интересен только
>как встраиваемая система, в пользовательскую десктоп систему, я считаю, он не
>вырастет никогда.

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

А насчет:

> Ну а если ты например ставишь систему на какой-нить
>Colibri PXA и еще не врубился как собрать и проинсталить пакет,
>то тут уж ничего не поможет.

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


"Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
Отправлено Максим , 25-Июн-08 12:19 
Мне все же кажется создовать такой Ари надо ,но для РАЗРАБОТЧИКОВ программ .Например есть
Такая програма как Firefox - хочеш установить обновление или дополнение ...хм если в пакетах нет то радости писать rpm что то не испытываю .