The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"OpenNews: Решит ли возрождение проекта Berlin API проблемы с..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [ Отслеживать ]

"OpenNews: Решит ли возрождение проекта Berlin API проблемы с..."  
Сообщение от opennews on 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.ru/opennews/art.shtml?num=16620

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

44. "*sigh*"  
Сообщение от Michael Shigorin email(ok) on 25-Июн-08, 01:52 
>Что тупорылая структура пакетов что сам манагер.

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

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

79. "*sigh*"  
Сообщение от Michael Shigorin email(ok) on 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) и весьма впечатляющей разработки по их автоматическому обнаружению (как сборочных, так и установочных; как для бинарников, так и для скриптовых языков).

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

39. "emerge рулит :)"  
Сообщение от himik email(??) on 24-Июн-08, 23:59 
emerge в Gentoo по моему неплохо справляется с задачей кдаления неиспользуемых пакетов..
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  
Сообщение от pavlinux email(ok) on 24-Июн-08, 17:11 
Он думал, - зачем ставить в RedHat, пакет от Ubuntu или от SuSE в Debian???
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  
Сообщение от Аноним (??) on 24-Июн-08, 17:27 
ИМХО там совсем нет системы этих самых пакаджей. Есть система портов, а это вовсе не одно и то же.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  
Сообщение от anonymous (??) on 24-Июн-08, 17:42 
Давно портировали, Gentoo называется. И удаление неиспользуемых пакетов работает.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

28. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  
Сообщение от Guest (??) on 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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

Да что вы?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

46. "*sigh*"  
Сообщение от Michael Shigorin email(ok) on 25-Июн-08, 02:11 
Нет, ну это просто феерическое нечто.

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

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

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

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

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

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

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

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

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

Поясните?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

84. "*sigh*"  
Сообщение от oops on 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", часто не понимая как она живет в реальных условиях и что с ней делать. Я вижу это каждый день.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

86. "*sigh*"  
Сообщение от pavel_simple (??) on 26-Июн-08, 08:20 
> Я вижу это каждый
>день.

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

91. "*sigh*"  
Сообщение от Michael Shigorin email(ok) on 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"...

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

81. "*sigh*"  
Сообщение от Michael Shigorin email(ok) on 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 куда быстрей приводят к появлению и улучшению языковых пар, чем домашняя машинка...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

61. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  
Сообщение от Осторожный on 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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

66. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  
Сообщение от .3 on 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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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


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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Да, он.

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

89. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  
Сообщение от oops on 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 нужно знать точное имя пакета. можно посмотреть в порту.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

90. "Решит ли?! :-D"  
Сообщение от Andrey Mitrofanov on 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 проблемы с инсталляцией ПО"?? :-))))

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

45. "какие пакаджи..."  
Сообщение от Michael Shigorin email(ok) on 25-Июн-08, 02:00 
>Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать
>её в Linux.

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

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

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

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

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

64. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  
Сообщение от Осторожный on 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 хорошая вещь, но все равно не решает всех проблем.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

69. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  
Сообщение от oops on 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 хорошая вещь, но все равно не решает всех проблем.

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


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

74. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  
Сообщение от .3 on 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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

59. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  
Сообщение от Knuckles email(ok) on 25-Июн-08, 09:27 
Спасибо, как устанавливать и удалять пакеты я сам знаю :)
Речь о другом:
http://www.opennet.ru/openforum/vsluhforumID3/42532.html#10
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

82. "слакваристы"  
Сообщение от Michael Shigorin email(ok) on 26-Июн-08, 02:29 
> это уж каждый кто устанавливает slackware должен знать сразу.

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

[*]

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

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

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

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

88. "ух ты, слакварист 8)"  
Сообщение от tux2002 email on 26-Июн-08, 11:07 

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

93. "'хэндбуки' и 'с пользователями'"  
Сообщение от Michael Shigorin email(ok) on 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 стараюсь делать так, чтоб было удобно и полезно себе и другим.  И это скорее правило по команде (хотя бывают заскоки, конечно).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

96. "буки' и 'с пользоват"  
Сообщение от tux2002 email on 26-Июн-08, 18:56 

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

98. "'хэндбуки' и 'с пользователями'"  
Сообщение от Michael Shigorin email(ok) on 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 -- проблемы последнее время бывали разве что вида "Саша медлит с релизом-с-буковкой, говоря, что там ещё сейчас патчик будет" :-)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

83. "транзакции"  
Сообщение от Michael Shigorin email(ok) on 26-Июн-08, 02:36 
>от транзакций на unix like осях лично я бы не отказался.

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

97. "транзакции"  
Сообщение от Michael Shigorin email(ok) on 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-шку в качестве бэкапа, пока пыль точно не осядет.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

А насчет:

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Ihor
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2019 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру