Джеф Джонсон (Jeff Johnson), четыре года назад основавший (https://www.opennet.ru/opennews/art.shtml?num=10931) проект RPM5 (http://rpm5.org/), в рамках которого был создан форк развиваемого компанией Red Hat пакетного менеджера RPM, объявил (http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel...) в списке рассылки разработчиков Mandriva о начале формирования проекта rpm6.org. Объявление было сделано после недельной недоступности сайта пакетного менеджера RPM5 и размещенных на нем систем отслеживания ошибок и репозиториев.В середине апреля Джеф Джонсон выразил (http://www.mail-archive.com/rpm-devel@rpm5.org/msg04891...) недовольство (http://www.mail-archive.com/rpm-devel@rpm5.org/msg04896...) политикой назойливого продвижения патчей в RPM5 разработчиками проекта Madnriva, мигрирующего на RPM5 в процессе подготовки релиза Mandriva 2011. Недовольство связано прежде всего в навязывании улучшений без их предварительного обсуждения, без тестирования, без примеров исп...
URL: http://www.osnews.com/story/24686/Jeff_Johnson_About_to_Fork...
Новость: https://www.opennet.ru/opennews/art.shtml?num=30441
что-то не в ту сторону пошел опенсорс :( так скоро все растащат и развалят
Похоже на некую форму рейдерского захват "по-русский". Вроде как фонд NGI руку прикладывает.
> Похоже на некую форму рейдерского захват "по-русский". Вроде как фонд NGI руку
> прикладывает.не знаешь - не придумывай.
Русские кодеры как раз был больеш всех против рпм5. И его в россии не патчат.
Извините, а их что там, уже спрашивать начали?
Как минимум, вас, неуважаемый шигорин, точно не спросят. Как и вашу камарилью Альта. Идите с миром. Желательно мимо.Шигорин, у вас, что какая то проблема? Вас не взяли работать в Мандриву? :))
интересно а что в России патчат?зыж
про ваши проблемы не спрашиваю. ведь у того кто ничего не делает проблем не бывает, не так ли? :D
> интересно а что в России патчат?Применительно к rpm5: cvs tourbin OR levin site:rpm5.org (у нас на конторе тоже напильник прикладывают, но этот форк ещё предстоит мержить -- вместе с патчами на ядро, эрланг и т.п.)
> зыж
> про ваши проблемы не спрашиваю. ведь у того кто ничего не делает
> проблем не бывает, не так ли? :DОбидно, что явно молодой человек не понимает происходящего.
Если российские разработчики были против, то решение о переезде на rpm5 (на фоне кучи других переездов) было либо самостоятельно принято бразильскими коллегами, либо спущено сверху. Предварительно и без раскопок/расспросов могу предположить (именно из-за "фона кучи"), что решение было принято сверху и целью его было "догнать, перегнать и ещё доказать инновационность".
При этом, видимо, также оказывалось давление по части продвижения патчей в апстрим -- что может быть правильным само по себе (при адекватном выделении на то ресурсов, как раз на днях докладывался на питерской ADDConf), но требует понимания того, как работают проекты по разработке свободного софта -- в отсутствии чего и укорял Комиссарова года полтора тому.
Сделать же аккуратный патч, пригодный для апстрима и других -- может быть в несколько раз более трудоёмко, чем нахакать быренько под свою ситуацию. Как показывает история с пингвиншрифтами -- это руководство скорее нацелено на быстрый пиар, чем на медленный полезный результат.
То есть резюмируя:
* при дуболомном управлении ссылаться на мнение разработчиков просто глупо -- они не определяют;
* освещение разработок важно, но не должно являться главной целью их проведения.
ээ, а почему столько агрессии?
расскажите и мне! я не в курсе
Аггрессия чья? У Шигорина? Его поставили на должность главного накидывателя на вентилятор в на каждом ресурсе, где указывается компания Пингвин или г-н Комиссаров. ОНи их обошли в конкурсе используя "открытый репозиторий" Альта. Альту стало обидно за что то, что они пиарили - мол нужен нацрепоз для всех желающих формировать опенсорцные продукты, ну вот кто-то и воспользовался им впервые по назначению и победил :))).
У меня-то неприязнь бывает по отношению к тем, кто врёт, притом с детства. По пунктам:- "его поставили" -- меня практически невозможно "поставить", кто знает -- подтвердит;
- "накидывателя на вентилятор" -- скажите, где неправ в публичном изложении того,
_чем_ является компания пингвинсофт и г-н Комиссаров: постараюсь исправить;
- "обошли в конкурсе используя открытый репозиторий" -- нет, использовалась крыша
"академии" АйТи в минобрнауки (один из совладельцев -- бывший замминистра);
- "Альту стало обидно" -- да если б у Комиссарова хоть совесть элементарная была
и намерение работать для людей, а не "бизнес крутить" (вспомнился инцидент
с болванками от Золотарёва), так и работали бы сообща над тем, у кого что лучше выходит;
- "впервые по назначению" -- погуглите слово ApplianceWare, _впервые_ AFAIK было оно.Проблема комиссаровых в том, что действуют они в точности по крыловской басне "свинья и дуб": краткосрочно подрезать "конкурента" додумываются, а о том, что если его угробить, то самому справиться просто не получится -- или не думают, или отметают как несущественное.
_Если бы_ Дмитрий хотя бы не был откровенно злонамеренным (я долго это выяснял, не хотел верить) -- то можно было бы пытаться что-то делать вместе. А так мой "пессимистический" прогноз полуторалетней давности пока оправдывается: http://gvy.livejournal.com/7283.html
PS: а расскажите-ка, из каких соображений это пишете? Интересно прям стало.
PPS: "в мандриву" я и не думал никогда идти -- не ищу работу, а работать предпочитаю с людьми вменяемыми, повидав разных.
Его не взяли работать в Альт =)
Меня приглашали работать в альт несколько лет тому -- но я достаточно давно собираю нашу команду, чтобы не искать работу.
s/опенсорс/мандрива/
>что-то не в ту сторону пошел опенсорс :( так скоро все растащат и развалятбред какой-то и большое заблуждение, что если все будут рыть один беломор-канал, то колбаса будет на прилавках в достатке.
зыж
патчей, форков и тд на всех хватит.
и что характерно - это никак не изменит количество готовых качественных продуктов и дистров.
а если хотите убедиться, то подпишитесь на рассылки.
например тут - http://vger.kernel.org/vger-lists.html - за день писем 1000. и половина из них с патчами.
при чём тут опенсорс? красношляпство уже давно не туда плывёт.
Форк форка?
Не совсем по теме, но такой вопрос: есть ли где наглядное сравнение пакетных менеджеров? Хотя бы наиболее популярных, типа deb, rpm, portage.
Если возможности dpkg и emerge я себе неплохо представляю, то rpm для меня вообще темный лес. А ведь есть еще и другие системы
а есть ли сильная разница между бинарными пакет-манагерами? или между сорцовыми (source)?rpm примерно соответствует dpkg. различаются некоторыми фичами и нюансами.
> а есть ли сильная разница между бинарными пакет-манагерами? или между сорцовыми (source)?Есть, конечно. Очень вкратце -- rpm более "дубовый", dpkg более "инженерный". Причём у обоих подходов свои плюсы и минусы.
> Очень вкратце -- rpm более "дубовый", dpkg более "инженерный".Что вы вкладываете в эти слова? Если по гибкости и настраиваемости, rpm далеко впереди.
Есдинственное преимущество deb - разрешение зависимостей может несколько быстрее происходить.
>> Очень вкратце -- rpm более "дубовый", dpkg более "инженерный".
> Что вы вкладываете в эти слова? Если по гибкости и настраиваемости, rpm
> далеко впереди.В rpm давным-давно были сделаны вещи вроде проверки контрольных хэшей и подписей -- в dpkg их очень долго не было (сейчас точно не помню, расскажите кто?).
В rpm зависимости скорее однозначны, а "вилки" разруливаются через виртуальные пакеты -- в dpkg реализованы булевы.
В rpm идёт сборка шелл-скриптами (хотя можно переопределить buildshell) по предопределённым секциям spec-файла -- в dpkg сборка на make плюс шаблоны (причём сборку с повторяющимся шаблоном на вагоне dh_* красивой у меня язык назвать не поворачивался).
Для расковыривания .rpm нужен хотя бы rpm2cpio -- для .deb достаточно coreutils.
Пакетные скрипты в .rpm неинтерактивны по определению (хотя технически можно занять stdin и повисеть) -- в .deb подразумевается возможность запуска (в т.ч. интерактивного) debconf.
Есть множество различий, в каждой точке выбор неоднозначен и тенденции для rpm/rpm и deb/dpkg мне в сумме кажутся именно "дубовыми/продуктовыми/энтерпрайзными" и "инженерными" соответственно. Что ни капельки не противоречит их происхождению.
PS: поймите, я не ругаю то или это. Просто разные взгляды на схожие задачи.
PPS: насчёт производительности при разрешении зависимостей как раз не знаю -- надо бенчмаркать, но ни в коем разе не судить по времени отрабатывания соответсвующей фазы аптом.
в dpkg зависимости прописываются вручную, по именам пакетов. в rpm - автоматически по именам линкуемых библиотек (то есть, по именам файлов, входящийх в пакет).
> в dpkg зависимости прописываются вручную, по именам пакетов. в rpm - автоматически
> по именам линкуемых библиотек (то есть, по именам файлов, входящийх в
> пакет).вот за это я бы rpm-щикам ручонки бы то пооторвал! За использование *прямых* имен либ в депендинсах вместо имен пакетов в которых они живут.
>вот за это я бы rpm-щикам ручонки бы то пооторвал! За использование *прямых* имен либ в депендинсах вместо имен пакетов в которых они живут.Отрывать надо тебе. За незнание ldd.
>>вот за это я бы rpm-щикам ручонки бы то пооторвал! За использование *прямых* имен либ в депендинсах вместо имен пакетов в которых они живут.
> Отрывать надо тебе. За незнание ldd.ты хоть фразу то мою понял, о чем она?
видимо нет, раз такую хрень несешь.
>ты хоть фразу то мою понял, о чем она?Ты хоть сам-то понял, что сказать хотел? Иногда лучше жевать.
Да нет, просто сослать на рудники зависимости и дальше руками прописывать.
А там, глядишь, осознает. :)
а вот тут не соглашусь.
вижу из примера соурсбэйзед дистров. к примеру на моей генте - имени пакета (порой виртуального) достаточно для того чтобы не привязываться ни к конкретной библе/ам, ни к её/их версии/ям.
опять же учитывая то, что все пакеты происходят от сырцов разработчиков, а мэнтейнеры их только собирают (да-да, и патчат тоже. но это всё же не разработка ни по объёму, ни функциональности)
зыж
и почему руками то? неужели есть сложности по имени либы узнать имя пакета автоматом?
если чё, то в дебиане/убунте собрать из сырцов деб не в пример легче, чем в большинстве рпм-дистров.
> а вот тут не соглашусь.
> вижу из примера соурсбэйзед дистров. к примеру на моей генте - имени
> пакета (порой виртуального) достаточно для того чтобы не привязываться ни к
> конкретной библе/ам, ни к её/их версии/ям.Если пакет уже собран, то ему нужна конкретная либа. А не просто либа с похожим названием, или даже теми же фунциями, но .so.1 а не .so.0
> опять же учитывая то, что все пакеты происходят от сырцов разработчиков, а
> мэнтейнеры их только собирают (да-да, и патчат тоже. но это всё
> же не разработка ни по объёму, ни функциональности)
> зыж
> и почему руками то? неужели есть сложности по имени либы узнать имя
> пакета автоматом?
> если чё, то в дебиане/убунте собрать из сырцов деб не в пример
> легче, чем в большинстве рпм-дистров.В rpm-дистрах просто устанавливается .src.rpm пакет. он автоматом собирается и компилируется. Все в одном файле. А в Дебиане три файла: тарболл с исходниками, огромный дифф со всеми патчами, собранными в кучу, и инструкция по сборке. И что проще?
и там и там все просто (у rpm к тому же не очевидно, когда src-пакет поставлен надо натравливать на спеку, у dpkg - одна команда в дереве сырцов). и там и там предварительно надо ставить сборочные зависимости. таки слухи о трех файлах преувеличены, если хочется свежий софт - подрубается сырцовая репа для unstable/experimental и оно таки все делает автоматически (три файла сами мержатся в один каталог для сборки) в одну команду. еще одна приятная фича - автоматическая установка зависимостей (я про apt-get build-dep имя пакета). а если уже зашла речь о том, как лучше софт опакетить - то тут лучше дебьяна нету: делаешь dh_make и потом получаешь все что надо. а есть ли у rpm чтото похожее (задача: собрать сырцы в пакет при отсутствии спеки.) checkinstall - не катит (он есть и для деба тоже)
По-твоему, в rpm нет установки сборочных зависимостей? Ну ты насмешил.
> в rpm нет установки сборочных зависимостей?Нету: он же не занимается репозиториями, а только пакетами и их множествами.
> таки слухи о трех файлах преувеличены, если
> хочется свежий софт - подрубается сырцовая репа для unstable/experimental и оно
> таки все делает автоматически (три файла сами мержатся в один каталог
> для сборки)Если тебе надо собрать из сорцов один-единственный пакет, не подрубая репозиторий, то тебе таки придется качать три файла.
> Если тебе надо собрать из сорцов один-единственный пакет, не подрубая репозиторий, то
> тебе таки придется качать три файла.а речь шла о пакетных менеджера, походу. но очень быстро перешла на ручную сборку без репозитариев. однако.
Речь шла и идет о формате пакетов rpm. С форматом rpm ты качаешь один файл c исходниками .src.rpm и собираешь его. С deb ты качаешь 3 файла: .tar.gz, .diff, и .dsc.
> Речь шла и идет о формате пакетов rpm. С форматом rpm ты
> качаешь один файл c исходниками .src.rpm и собираешь его. С deb
> ты качаешь 3 файла: .tar.gz, .diff, и .dsc.Вы выдумываете какой-то экзотический случай. Ну или я не догоняю суть. Менеджер пакетов качает и собирает. Если он этого не делает, это либо хреновый менеджер пакетов, либо хреново выбранный дистрибутив. Если акция разовая - 1 файл качать или 3 - неважно. Если сборка руками - вещь постоянная, где-то кто-то промахнулся с выбором дистра. Опять-таки, я могу ошибаться, ибо rpm использовал давненько (Fedora/ALT), но как раз при частом наличии экзотических сборок софта регулярно выбираем FreeBSD/gentoo. Сколько файлов качает emerge/portinstall абсолютно по барабану.
Дядьки, да не спорьте :)Давайте лучше на wiki.opennet.ru нарисуем страничку по пакетным менеджерам да отрихтуем, если кто в чём вдруг ошибся. По rpm постараюсь помочь, но прямщас с дороги не обещаюсь (так что буду благодарен за лишнее уведомление письмом, если кто всё же доберётся).
И в категорию "Сравнение" её.
>Если пакет уже собран, то ему нужна конкретная либа. А не просто либа с похожим названием, или даже теми же фунциями, но .so.1 а не .so.0угу, и при чём такая есть точно во-о-он в том пакете конкретной версии. :D
но НЕ во-о-н в том пакете, где есть точно такая же библа с тем же именем, но в 3-и раза меньше по размеру.
не слышали про конфликтующие пакеты? не?
>В rpm-дистрах просто устанавливается .src.rpm пакет.а кто ж создает то эти .src.rpm пакеты?
>>Если пакет уже собран, то ему нужна конкретная либа. А не просто либа с похожим названием, или даже теми же фунциями, но .so.1 а не .so.0
> угу, и при чём такая есть точно во-о-он в том пакете конкретной
> версии. :D
> но НЕ во-о-н в том пакете, где есть точно такая же библа
> с тем же именем, но в 3-и раза меньше по размеру.Если либа имеет другой API, то и имя файла с либой будет другимм. Будет .so.1 а не .so.0. Две либы с разным API но одним именем файла не бывает.
> не слышали про конфликтующие пакеты? не?
>>В rpm-дистрах просто устанавливается .src.rpm пакет.
> а кто ж создает то эти .src.rpm пакеты?Служба сборки?
Ты можешь прописывать и имена пакетов, в дополнение. Просто без них - по одним либам - портабельнее, и дистрибутив в целом разивать удобнее.Например, очень типичная ситуация - есть пакет megaproga, он собран с библиотекой megaliba.so, которую предоставляет пакет usefulstuff. В какой-то момент мейнтейнер пакета usefulstuff решил, что многим оттуда нужны только библиотеки, и бинари и доки - только иногда, и разделил его на usefulstuff-libs, usefulstuff-progs и usefulstuff-docs. Если зависимости были прописаны только rpm'ом автоматически, то по зависимости megaproga: megaliba.so пакетный менеджер вроде yum или apt автоматически найдет, что эта библиотека предоставляется пакетом usefulstuff-libs. Или, скажем, можно обновить usefulstuff -> usefulstuff-libs + usefulstuff-progs при установленной megaproga; зависимости соблюдены, ведь megaliba.so в системе.
А вот если мейнтейнер megaproga решил с дуру продублировать зависимость на имя пакета вручную (хотя иногда, конечно, это имеет смысл, например зависимости к megaproga-data), то опаньки, обновиться с usefulstuff на usefulstuff-libs при установленной megaproga не выйдет, завимости будут нарушены. Нужно пересобирать megaproga. (хотя в реальной ситуации у usefulstuff-libs может быть прописано provides: usefulstuff и obsoletes: usefulstuff < x.y, и все пройдет нормально). Профита от ручных зависимостей никакого, а недостатки есть.
Ну а то, что rpm при попытке установить в обход yum напишет об отсутствии зависимости "megaliba.so", а не "megaliba.so и usefulstuff" - это сущие мелочи. Да и если приспичит, yum можно вручную попросить найти имя пакета по библиотеке - актуальное для текущей базы, а не в момент сборки megaproga. А до популяризации yum это делалось средствами rpm, по базе comps.
ваше описание совершенно справедливо, если оно относиться к бардачно-ориентрированному дистрибутиву.есть другие сложности с либами - трудно заранее выяснить, какому src.rpm принадлежит либа (и не обязательно либа!) прямо указанная в спеке. Это нужно для постороения однопроходного дерева для сборки всего репоза. Потому то всякие вендоры и портят стандарт и сидят на старом RPM ни с кем не совместимом, что решают такие проблемы.
вопросы сборки 1го или 10ти пакетов - не проблема.
Почему это трудно?
Можно как внешними средствами, так и голым рпм. Пример с rpm:Шаг 1. Создаете базу, аналогичную comps - rpmdb, где отмечены все пакеты
Шаг 2. rpm --dbpath /путь/к/comps -q --whatprovides <хитрая либа или не обязательно либа> --queryformat "%{sourcerpm}\n"Вот и все. Работает в ЛЮБОМ rpm 4 и, подозреваю, в rpm 3 тоже.
дада, когда есть нормальный бинарный репоз - все смелые)а когда в репозе у тебя бинарий которому сорец не соответствует, или вообще отсутствует - вот тут приплыли. говорю же - проблема не надумана. совсем невозможно - когда у тебя *только* сорцевый репоз + гцц и пара либ. как тебе бутстрапом раскрутить дерево сборки всего репоза если еще метаданных для несобранных бинариев не существует, потому что их еще не собрали?? в дебиане таких проблем физически быть не может, потому что чрут для сборки пакета формируется на основе только имен пакетов, а не файлов о которых пока не известно из какого пакета они *потом* родятся.
ваш пример из серии - откуда деньги? из тумбочки! ;) - на основе УЖЕ кем то и когда то подготовленного репоза.
> а когда в репозе у тебя бинарий которому сорец не соответствует, или
> вообще отсутствует - вот тут приплыли.Это где такие чудеса бывают? В каком дистрибутиве?
Вероятно, в помойке под руками. В альте-то все _символы_ с 2005 года как минимум учтены, не то что сонеймы: http://lists.altlinux.org/pipermail/devel/2008-December/1650...
Пожалуйста, не выдумывайте проблем там, где их нет. В rpm их, во всяком случае, нет.Ваша задача для одного пакета решается с помошью mock, который автоматизирует данную операцию - собирает chroot для сборки данного пакета, ставя внутрь все необходимые зависимости (и ему, сюрприз, вообще без разницы, что стоит в базовой системе - можно хоть i386 внутри чистой x86_64 собирать - он собирает информацию о том, что где находится прямо из метаданных по репозиторию). Для сборки ВСЕГО дистрибутива создана (конечно, монстрообразная. А вы что хотели, дистрибутивы массово клепать на коленке? это можно, но другими инструментами, которые не пересобирают все с нуля) система koji. Которая используется, в частности, для сборки всех версий fedora и redhat - и ни-ког-да ни у кого не было тех проблем, о которых вы пишете.
koji - это не система сборки "из ничего вообще", потому что это не имеет смысла. Это система непрерывной сборки, когда новое собирается на пакетной базе старого. "начала", из которого прямо получается результат как такового нет, вы можете как начало взять все, что вам нравится, через несколько итераций - примерно как двойная пересборка gcc самим себя - все версии зафиксируются в то, что нужно.
Вы, наверное, скажете, что это не то, что вы хотели - ну что ж, извините. В плане сборки дистрибутивов (да и не только их, тот же gcc+glibc+etc в пример, когда рекомендуется пересобрать все снова и снова при изначальной сборке) обычно делают именно так. Даже LFS начинает собираться на хост-системе - но благодаря итерационной пересборке становится самостоятельным и _независимым_ от нее. Koji реализует то же самое, только вместо хост-системы у нас постоянно устаревающая пакетная база.
"Подготовленного кем-то репоза"? Да поймите вы, это не имеет значения :) Совершенно новая и независимая сборка нового дистрибутива просто ИСПОЛЬЗУЕТ старый репозиторий вначале, как LFS использует хост-систему, а потом выходит на самоподдержку. А что у вас там было в начале, вообще неважно.
Кстати, у центоса не было бы таких жутких проблем со сборкой RHEL6, если бы у них был koji или его аналог; но для них это слишком тяжелая система, а по ресурсам они ограничены (koji требует много места для нескольких поколений пакетов и много ресурсов при итерационной пересборке), поэтому и них своя простенькая система, но им тяжело собрать в ней дистрибутив, рассчитанный на принципиально другую систему создания с нуля. Кстати, у них тоже нет бустраппинга - у них тоже итерационный метод, но начинался от с базы centos 5, которая слишком стара. Но все-таки она намного примитивнее koji, и адаптировать сборку к ней довольно сложно
> Пожалуйста, не выдумывайте проблем там, где их нет. В rpm их, во
> всяком случае, нет.
> Ваша задача для одного пакета решается с помошью mock, который автоматизирует данную
> операцию - собирает chroot для сборки данного пакета, ставя внутрь все
> необходимые зависимостиОх! А мужики то и не знали :) Но вы не внимательно читаете - я сказал следующее: Есть только сорцевый репоз и базовый минимальный инструментарий для его сборки. НЕТУ большого бинарного репоза откуда по зависимостям формируются чруты для сборки пакетов. НЕ-ТУ. И постоить однозначно граф для однопроходной сборки достаточно тяжело, т.к. НЕТУ возможности вычилить заранее - в каком бинарном пакете родится либа, которая указана явно как файл в депендинсах. Для деб-репоза такой проблемы не существует. Для рпм - существует. Они решаются конечно, но криво и без самогенерации на основании только сорцевого репоза. Приходиться где-то брать метаданные от ранее собранного бинарного. А это уже подлог.
Молодей человек, я уже не 1й раз готовлю систему для ФСТЕК. Я не умаляю познания местной публики в мантейнинге, но у вас совсем другие задачи стоят, где проблемы рпм-а не видны.
> НЕТУ возможности вычилить заранее - в каком бинарном пакете родится либа, которая указана явно как файл в депендинсахЧто-то вы тут явно не договариваете.
Зависимости _для сборки_ в rpm прописаны явно, по именам пакетов. (не припоминаю, чтобы кто-либо прописывал либы). Соответственно, чтобы собрать, информации о том, что надо доставить в srpm достаточно. Где вы видели зависимость сборки *от либы*?? Граф однопроходной сборки замечательно строится на основе build-requires (+ подразумеваемый rpm-build со своими зависимостями - но тут уж извиняйте, инструмент для сборки кроме как итерационной сборкой вначале в хост-системе, потом в вашей не получить никак). Зачем вам вообще метаданные от бинарного, если ваша задача - собрать дистрибутив? И какое вам дело до автоматических зависимостей к либам у уже собранных пакетов, вы же говорите, что начинаете только с исходников??(центосу они нужны, т.к. у них в отличие от SL и большинства rpm-based дистрибутивов вообще очень специфическая цель - собрать таким хитрым образом, чтобы у свежесобранного пакета ссылки на библиотеки были идентичными тому rpm, который они пытаются повторить - это действительно нетривиальная задача в rpm, но тут не думаю, что в deb тут чем-то легче, да и очень специфическая задача, с которой обычно никто не сталкивается).
> Ох! А мужики то и не знали :) Но вы не внимательно
> читаете - я сказал следующее: Есть только сорцевый репоз и базовый
> минимальный инструментарий для его сборки. НЕТУ большого бинарного репоза откуда по
> зависимостям формируются чруты для сборки пакетов. НЕ-ТУ. И постоить однозначно граф
> для однопроходной сборки достаточно тяжело, т.к. НЕТУ возможности вычилить заранее -
> в каком бинарном пакете родится либа, которая указана явно как файл
> в депендинсах.По либам автоматически зависимости прописываются уже ПОСЛЕ сборки. На основании вывода линковщика. Devel-пакеты, нужные для сборки перечислены явно в спеке в теге "BuildRequires:".
Думаю, он о том, что "надо собрать пакет A -- как выяснить, сколько ещё чего придётся рекурсивно собрать поверх минимально забутстрапленого репозитория, чтоб это стало возможно с учётом BuildRequires".Куда смотреть -- _этим_ красавцам не скажу.
Или например, есть пакет libmegalib-1.0 с либой libmegalib.so.0 и более новая версия libmegalib-2.0 с либой libmegalib.so.1. Пакетный менеджер rpm знает, что в новом пакете старой либы нет, и не станет обновлять, если старая либа используется какой-ито программой. А Дебиан сразу обновит, потому что название то же, а версия новее. Результат - неработающие пакеты, которым нужна libmegalib.so.0.
данная ситуация настолько редкая, что возникает чуть чаще чем никогда (я говорю о debian stable + backports, а не о красноглазом sid+experimental, где данное событие таки может иметь место, но это же не продакшен...)
> данная ситуация настолько редкая, что возникает чуть чаще чем никогда (я говорю
> о debian stable + backports, а не о красноглазом sid+experimental, где
> данное событие таки может иметь место, но это же не продакшен...)Это означает, что людям вручную это приходится контролировать.. стараются контролировать в stable получше, в sid не так сильно.. это, как бы, фейл. С автоматической системой зависимостей ничего само не сломается, пакетный менеджер контролирует автоматически.
> данная ситуация настолько редкая, что возникает чуть чаще чем никогда (я говорю
> о debian stable + backports, а не о красноглазом sid+experimental, где
> данное событие таки может иметь место, но это же не продакшен...)Вот смотри, я могу подключить на openSUSE репозиторий Федоры и не бояться ни за что. И знаешь почему? Потому что я знаю, то система не обновит пакеты, в которых поменялся API. Не удалит ни одну либу, на которую что-то слинковано.
Посмотрел бы как ты сделаешь то же самое с убунтой или дебианом, даже подключив реп от другого релиза. И это даже не смотря на то, что Fedora и openSUSE - совершенно разные, никак не связанные дистрибутивы.
В альте сделали следующий шаг и реализовали зависимости на библиотеки по слепку ABI (хэшу предоставляемых символов): http://ftp.linux.kiev.ua/pub/conference/peers/pereslavl/2010... ("Комплементарное хеширование подмножеств", с.63).Т.е. если в апстриме де-факто сломали ABI, но не сменили soname, то всё равно пакетная база не сломается незаметно.
PS: Вы тоже говорите про бинарный, а не программный, интерфейс. :) API -- гругря, build time.
> А Дебиан сразу обновит, потому что название то же, а версия новее.Там для этого стали soname втаскивать в название пакета -- в pool будут _пакеты_ libmegalib0 и libmegalib1, пока хоть какой-то пакет там же будет ещё требовать старый сонейм.
PS 2 Stax по поводу mock и koji: в альте давно есть hasher и mkimage (когда-то был интегрированный sandman, а ещё с тех пор появился gear; см. странички на вики) -- интересно, что в нынешней федоре является аналогом альтовского http://www.altlinux.org/buildreq? (хотя это, пожалуй, тоже уже офтопик совсем)
> хотя в реальной ситуации у usefulstuff-libs может быть прописано
> provides: usefulstuff и
> obsoletes: usefulstuff < x.y, и все пройдет нормальноНе помню точно, но Provides: лучше прописывать с точным версионированием, e.g.
Provides: usefulstuff = %version-%release
(иначе можно ненароком напороться на self obsoletes при пересечении версий, особенно если это не порезка/переименование пакета с продолжением монотонного роста версии, а смена альтернативных источников)
>> в dpkg зависимости прописываются вручную, по именам пакетов. в rpm - автоматически
>> по именам линкуемых библиотек (то есть, по именам файлов, входящийх в
>> пакет).
> вот за это я бы rpm-щикам ручонки бы то пооторвал! За использование
> *прямых* имен либ в депендинсах вместо имен пакетов в которых они
> живут.Почему? Так получается гарантия, что все нужные либы для пакета будут установлены, не зависимо от названия и версии пакета. Если в новой версии нужной либы нет, пакет не будет обновляться. Не то, что на Дебиане.
И потом, может быть два пакета с одним именем, но содержащих совсем разные программы - это никого в rpm-системе не волнует. А на Дебиане надо имена пакетов согласовывать, нельзя переименовывать, не ломая зависимости и т.д.
В rpm так же указываются зависимости к пакетам. Зависимость к библиотекам - это доп. фитча.
> В rpm так же указываются зависимости к пакетам. Зависимость к библиотекам -
> это доп. фитча.Зависимости по именам пакетов ставятся только если нужный пакет не слинкован, а например, содержит какие-то скрипты или данные и т.д. В 90% случаев (Си, Питон и т.д.) зависимости проставляются автоматом и туда лучше не вмешиваться.
> вот за это я бы rpm-щикам ручонки бы то пооторвал! За использование
> *прямых* имен либ в депендинсах вместо имен пакетов в которых они живут.Вы никогда не сталкивались с тем, что один и тот же soname/ABI может предоставляться разными пакетами? DSO HOWTO хоть читали? Теорию множеств проходили?
Видимо, нет. А туда же -- ляпать языком по форумам то, что в лицо сказать струсите.
> Не совсем по теме, но такой вопрос: есть ли где наглядное сравнение
> пакетных менеджеров? Хотя бы наиболее популярных, типа deb, rpm, portage.За твоим вопросом могут скрываться 4 совершенно ортогональные вещи:
1) формат бинаря пакета (.deb/.rpm и тд)
2) функциональность низкоуровневых утилит (dpkg/rpm и тд)
3) функциональность низхкоуровневых утилит типа zypper/yum/apt (и тд)
4) способ сборки пакетов из исходных тарболов (rpm_spec, debian/rules, pkgsrc и тд)Пункты 1 и 2 как правило ходят рядом. .rpm - это практически всегда rpm.
.deb -- dpkg, но в принципе могут быть и другие варианты.NetBSD = nih + pkg_* + .tgz + pkgsrc + distbb
RHEL = yum + rpm + .rpm + rpm_spec
Debian = apt/aptitude + deb + .deb + debian/rules
SuSE = zypper + rpm + .rpm + rpm_spec + OSBS
AltLinux = apt + rpm + .rpm + rpm_spec + hasherSuSE предлагет среди прочего, например, .deb + rpm_spec + osbs.
Я вот сейчас обдумываю такую комбинацию
yum + rpm + pkgsrc + distbb
Что вообще можно сказать о людях, использующих cvs?
> Что вообще можно сказать о людях, использующих cvs?Что они во-первых изрядно ленивы но во-вторых достаточно продуктивны, чтобы иметь возможность позволить себе беззаботно лениться.
> Что вообще можно сказать о людях, использующих cvs?То же, что и о людях, использующих SVN, ибо нет принципиальной разницы.
Наводит на мысль, что проблема не в Red Hat или Mandriva, а в Джефе Джонсоне, которому ну очень нравиться форкать RPM. Главное все время увеличивать номер версии, чтобы форк казался новее и прогрессивнее оригинала. У Red Hat вон до сих пор RPM 4.x. Не этично это, делая форк называть его так, как будто это более новая версия исходного проекта.
Этот Jeff Johnson особо "Этичностью" никогда не отличался. пруф https://bugzilla.redhat.com/119185
Ну и что там? Ему нахамили, от слегка на стену полез. Потом таки пофиксил баг.
Jeff Johnson уволили за это из Red Hat:https://bugzilla.redhat.com/show_bug.cgi?id=119185#c74
==========
Ken Snider 2006-06-08 16:27:25 EDT
http://www.kuro5hin.org/story/2006/6/5/101431/9311
If this can be believed, Jeff Johnson lost his job as a result of this ticket.
==========
> Наводит на мысль, что проблема не в Red Hat или Mandriva, а
> в Джефе Джонсоне, которому ну очень нравиться форкать RPM.Видите ли, он его в редхате и пилил (да, про тот посыл кастомера в курсе).
PS: если кто думает, что я на горе-манагеров вроде Комиссарова зря ругаюсь -- вот вам PingWinSoft, вот вам "Роса Лаб", вот вам участие в "разработке" Mandriva и особенно апстримных проектов -- кушайте, не обляпайтесь :-(
PPS: слышал, что текущее состояние Mageia (уволенные французские разработчики) намного вменяемей того, что получается у Mandriva. Сам _не_ смотрел, но человеку в этом вопросе склонен верить.
>слышал, что текущее состояние Mageia (уволенные французские разработчики) намного вменяемей того, что получается у Mandriva.Так это всего лишь 2010.2 с обновлёнными кедами и картинками. Там даже hal ещё торчит. Но, скажу честно, и от экспериментов "новой" мандривы тоже начинает бесить. Особенно "порадовали" эти танцы с rpm5 и "улучшенный" инсталер.
По моему опыту -- если что-то инкрементально доводить, шансов на то, что будет работать -- в среднем по больнице больше, чем если бросаться делать прыжки в ширину.
Да там много не поменялось, только софт свежий. Смотрю их беты, вроде нормально. Сам планирую с мандривы на нее перейти, когда зарелизится. Или может чуть раньше.
Интересный вопрос, но нафига rpm5 был нужен мандриве? Всё и так работало как часы.
Да-да, мне вот тоже интересно. Знает кто нибудь?
Зато теперь как весело https://qa.mandriva.com/show_bug.cgi?id=63177
Ну просто прелесть сегодня прилетело на голову =)
Это кукер, ему можно.
А решение в коментах к багу.
> Это кукер, ему можно.
> А решение в коментах к багу.Ну пока более нигде как в кукере rpm5 нет, так что пример показательный.
Решение значительно проще =) Нужно иметь локальную репу с возможностью отката. rsync в этом смысле выручает =)Ну и правда это один фиг не решение. Посмотрим как быстро закроют.
Подождём релиза. Ой чую этот переход на пятый рпм ещё не раз аукнется. И пока на задаваемый мной из темы в тему вопрос "на пуркуа переходить на рпм5" мне никто так и не ответил внятно.
Ну да посмотрим что будет дальше.
Кому нужна "классическая Mandriva" есть Mageia
> Кому нужна "классическая Mandriva" есть MageiaИ это здорово. Но я пока ещё понаблюдаю ибо нужно иметь время для постепенного перехода. А так да уде крутим поманеньку.
> Кому нужна "классическая Mandriva" [...]С таким управлением вопрос может перейти в плоскость фигурно процитированного. :(
> Да-да, мне вот тоже интересно. Знает кто нибудь?Они говорили, что им не дают нормальный rpm пропатчить как они хотят. Похоже, с новым у них та же прпоблема.
>> Да-да, мне вот тоже интересно. Знает кто нибудь?
> Они говорили, что им не дают нормальный rpm пропатчить как они хотят.
> Похоже, с новым у них та же прпоблема.Интересно кто не даёт? =) Патчи в апстрим не принимают? Дык наверное они попросту больше никому не упёрлись.
Кто мешал "локально" патчить хоть запатчиться не ясно. Вот терь в итоге будут тянуть что-то фиг с чем совместимое основанное на брошенной ветке. Или терь ждём перехода на rpm6 ? =) А потом через неделю 7мь и т.д. =)
Грил боком всё это дело выйдет, вот как в воду глядел.
>>> Да-да, мне вот тоже интересно. Знает кто нибудь?
>> Они говорили, что им не дают нормальный rpm пропатчить как они хотят.
>> Похоже, с новым у них та же прпоблема.
> Интересно кто не даёт? =) Патчи в апстрим не принимают? Дык наверное
> они попросту больше никому не упёрлись.
> Кто мешал "локально" патчить хоть запатчиться не ясно. Вот терь в итоге
> будут тянуть что-то фиг с чем совместимое основанное на брошенной ветке.
> Или терь ждём перехода на rpm6 ? =) А потом через
> неделю 7мь и т.д. =)
> Грил боком всё это дело выйдет, вот как в воду глядел.Они говорят, что патчили локально, но им это надоело.
> Они говорят, что патчили локально, но им это надоело.Теперь снова это будут делать локально в песочнице =)
А какие такие дистрибутивы уже используют рпм5?
> А какие такие дистрибутивы уже используют рпм5?Alt Linux
>> А какие такие дистрибутивы уже используют рпм5?
> Alt LinuxЭто неверная инфа.
У альтов старый древний rpm 4.0.4, насквозь пропатченный под их дистрибутив. Там столько патчей наложено под их инфраструктуру, что они даже не рискуют переходить на более свежую версию.
http://packages.altlinux.org/en/Sisyphus/srpms/rpm
>> А какие такие дистрибутивы уже используют рпм5?
> Alt LinuxНет -- хотя для минимум одного дистрибутива на базе ALT существуют сборки rpm5 (и если кому нужна такая реализация биарча -- пишите).
>>> А какие такие дистрибутивы уже используют рпм5?
>> Alt Linux
> Нет -- хотя для минимум одного дистрибутива на базе ALT существуют сборки
> rpm5 (и если кому нужна такая реализация биарча -- пишите).Неправда, вот тут написано, что Alt использует rpm5: http://lwn.net/SubscriberLink/441085/1ffe908a85079f4f/
>>>> А какие такие дистрибутивы уже используют рпм5?
>>> Alt Linux
>> Нет -- хотя для минимум одного дистрибутива на базе ALT существуют сборки
>> rpm5 (и если кому нужна такая реализация биарча -- пишите).
> Неправда, вот тут написано, что Alt использует rpm5: http://lwn.net/SubscriberLink/441085/1ffe908a85079f4f/Не исключено, что кто-нибудь в ALT Linux Team в своём Git'е потихонечку ковыряет RPM5, но в Сизифе его пока нет:
http://packages.altlinux.org/en/search?utf8=✓&query=rpm
Нет, не использует (если только я не упустил такой новости за прошедшую неделю, хотя явно бы донеслось). Но это возможно.
а в opensuse какой rpm?
4.*
~> rpm --version
RPM version 4.8.0
Дык, получается, что, RPM5 мандриве подарили?
> Дык, получается, что, RPM5 мандриве подарили?А я тоже не понял, кому какая версия причитается после развода. Из новости ничего не следует. Можно лишь догадываться, что шеф взял номерок побольше для себя, а нынешнюю версию оставил мандривам.
Не легче Мандриве у себя в репах было сделать сборку RPM5 со своими дистрибутиво-специфичными патчами, чем доводить ситуацию до конфликта?
> Не легче Мандриве у себя в репах было сделать сборку RPM5 со
> своими дистрибутиво-специфичными патчами, чем доводить ситуацию до конфликта?Не получалось бы говорить про "работу с апстримом", не соврав.
Если пытаться пропихивать мандриву в российский госсектор (NGI/Рейнман), то при текущем уровне осознания вопроса в минэкономразвития etc такая работа может оказаться не пустым звуком, а плюсом.
Иллюстрация получилась просто шикарная, только не в ту сторону...
>> Не легче Мандриве у себя в репах было сделать сборку RPM5 со
>> своими дистрибутиво-специфичными патчами, чем доводить ситуацию до конфликта?
> Не получалось бы говорить про "работу с апстримом", не соврав.
> Если пытаться пропихивать мандриву в российский госсектор (NGI/Рейнман), то при текущем
> уровне осознания вопроса в минэкономразвития etc такая работа может оказаться не
> пустым звуком, а плюсом.
> Иллюстрация получилась просто шикарная, только не в ту сторону...Согласен со всем! Лихие 90-е. Бизинез по-русски.
Вопрос в том - а был ли мальчик?По сути разговор свелся к словесной перепалке. Работа как шла, так и идет. Особенно в свете будущего urpmi и отказе от Perl. А rpm5, rpm6, rpm7 - это так, вехи истории.
> Вопрос в том - а был ли мальчик?
> По сути разговор свелся к словесной перепалке. Работа как шла, так и
> идет. Особенно в свете будущего urpmi и отказе от Perl. А
> rpm5, rpm6, rpm7 - это так, вехи истории.Нуу, вот где работа точно идет - это в основной ветке rpm (http://www.rpm.org/). Ченжлоги вполне себе приятные, http://www.rpm.org/wiki/Releases/4.8.0 или http://www.rpm.org/wiki/Releases/4.9.0 например. А в rpm5.. вообще непонятно, что, с учетом, что кроме мандривы практически все используют обычный rpm, а не этот.
А что там про будущее urpmi интересного?
> А что там про будущее urpmi интересного?Развивается. Участились предложения сделать его независимым кросс-платформенным пакетным менеджером. http://lists.mandriva.com/cooker/2011-05/msg00032.php
Во... То есть скоро обычный rpm превратится в RPM5 :) Куда после 4.9.0 нумероваться то? ;)
неожиданно
4.10.0
> Вопрос в том - а был ли мальчик?Всё смешалось в доме Облонских...
Взяли RPM5, имея свой карманный URPMI, в итоге RPM5 оказался не нужен, решили развивать URPMI. Как-то всё непонятно там у них в Мандриве -- пакетный менеджер - это базовая часть, не то что можно менять как перчатки для каждого релиза, иначе о каком качестве дистра может идти речь?
И да, интересно, какой пакетный менеджер теперь будет в Мандриве 20011 в свете произошедших событий?
>И да, интересно, какой пакетный менеджер теперь будет в Мандриве 20011 в свете произошедших событий?да-да, интересно!
думаешь доживём? :D
> И да, интересно, какой пакетный менеджер теперь будет в Мандриве 20011 в свете произошедших событий?URPMI. Версия rpm - rpm5.
> Не легче Мандриве у себя в репах было сделать сборку RPM5 со
> своими дистрибутиво-специфичными патчами, чем доводить ситуацию до конфликта?жил был rpm5 и никому он был не нужен.
mandriva решила довести до ума этот продукт и ни какими-то своими патчами, а официально все свои наработки влить в заброшенный продукт.
а теперь он виновата - потому что проявила активность. маразм.
а не ошибается только тот кто ничего не делает
> а теперь он виновата - потому что проявила активность. маразм.Мандриву обвинили не в том, что она проявила активность, а в том, что она начала пихать в апстрим дистро-специфичные патчи, а также сырые патчи без должного обсуждения и документирования. Понятно, что разрабы апстрима не пришли от этого в восторг.
>> а теперь он виновата - потому что проявила активность. маразм.
> Мандриву обвинили не в том, что она проявила активность, а в том,
> что она начала пихать в апстрим дистро-специфичные патчи, а также сырые
> патчи без должного обсуждения и документирования. Понятно, что разрабы апстрима не
> пришли от этого в восторг.Мы тогда с Джеффом пообщались -- насколько понимаю, ему сломали регрессионные тесты, производимые на гораздо более развесистых, чем дистрибутивные, сборочных конфигурациях rpm5.
Ну и так не делается, когда сперва тормозят подписать контракт по фактически проделанной работе, а потом на публичном форуме предлагают фултайм по этому самому направлению (https://www.opennet.ru/openforum/vsluhforumID3/76875.html#142). Хотя это уже прямое следствие, но не часть обсуждаемой здесь истории.
рпм6 собиралась же редхат разрабатывать, пропустив рпм5.
(Я начал писать ответы на некоторые коментарии, но они появлялись быстрее чем я их успевал читать, так что отвечу сразу на все :))Новость очень сильно преувеличивает и я бы даже сказал искажает некоторые факты :). Как jbj, так proyvind апстрим-разработчики rpm в течении последних лет, и те, кто следят за кукером, я думаю особо не обратили на это внимание. По похожим поводам они уже месяцев 5 воюют, с ноября если точнее, достаточно просто посмотреть на архивы. Причем ни один из них на Мандриву не работает, они со стороны коммунити участвуют :).
В данном конкретном случае, к сожалению, дискуссия опять перешла в сторону mdv vs mga, и суммируя это с предыдущим эпическим флеймом по поводу того, что разработчики Mageia требовали доступ к svn РОСЫ чтобы включить эти разработки в их дистрибутив, где дискуссия тоже шла на очень повышенных тонах, я думаю джеффа это довело что он сказал что нечего разработчикам из Магеи катить бочку на rpm5, если по их мнению он и так "fiasco". Будет rpm5, где per oyvind будет рулить; и будет rpm6 как возможный новый будующий проект для исследований. Во что это превратилось в интерпретации osnews....
На lwn только что появилось более взвешенное мнение, советую его тоже почитать: http://lwn.net/SubscriberLink/441085/1ffe908a85079f4f/
Ну и кроме того, я думаю что коллеги из Альта со мной согласятся, если я скажу что у Jeff'а очень специфический стиль общения (как он сам говорит, jbjerish :)).
Я не понял. По вашей ссылке написано, что rpm5 использется в Alt Linux, а в этом треде выше люди это опровергают.
> Я не понял. По вашей ссылке написано, что rpm5 использется в Alt
> Linux, а в этом треде выше люди это опровергают.http://en.wikipedia.org/wiki/RPM_Package_Manager#RPM_v5
http://rpm5.org/team.phpХотя людям из Альта лучше знать конечно, я тут не авторитет :)
Да, с Джефом сложно работать. Я упоминал как-то про очень непростой апстрим rpm5.Что же касается разговоров про rpm5 в Альт, то они меня просто обескураживают. Откуда такая вера журналистам? Можно ведь просто посмотреть пакет.
Наш rpm можно было бы назвать любым номером, -- он ответвился от rpm-4.0.4 и, сохраняя совместимость, имеет очень много особенностей. Неприятно, конечно, отсутствие единого апстрима и "война версий", начатая Джефом, но особенности развития системы очень сильно связаны с управлением пакетами и если вы не простой клон, то всегда уйдете в сторону, реализуя свое понимание.
Впрочем, http://users.livejournal.com/aen_/128793.html ;-)
Тот факт, что, якобы, Альт использует rpm5 преподносился как одно из оснований, почему Мандрива должна на него перейти. Мол, вот история успеха. А что ж теперь получается? Мандрива - единственная, чтоли, из более-менее известных дистров на rpm5?Они еще пишут что на rpm5 перешел Ark. Это правда?
Нет. Там 4.4.5
А откуда тогда вот этот тред?
> Нет. Там 4.4.5
> Будет rpm5, где per oyvind будет рулитьКстати, да - если у кого есть желание поработать над RPM5 на fulltime пишите мне на почту (denis.koryavov на росалабе). :)
> Кстати, да - если у кого есть желание поработать над RPM5 на fulltimeДенис, извини, но я тебе даже патчи не пришлю, не то что людей.
Rosalab delendum est. Как и Карфаген -- оплот сатанизма в своё время.
> Денис, извини, но я тебе даже патчи не пришлю, не то что людей.Миша, а я тебя и не спрашивал.
> Rosalab delendum est.
"delenda est" вообще-то, если уж на то пошло.
> Миша, а я тебя и не спрашивал.Заметь, Джефф сам заглянул на огонёк и заметил, что пока его труд на халяву -- другим денег предлагают.
> "delenda est" вообще-то
Да, так должно сработать. :)
это же очень хорошо, когда каждый пилит свой пакменеджер с блекджеком и феями. свобода ;)
Интересно как они там ругаются:
> Интересно как они там ругаются:
> http://lists.mandriva.com/cooker/2011-04/msg00483.phpИм надо выучить русский язык, тогда бы они смогли ругаться ещё эффективнее -- с матом :)
Ой, народ, не могу, это цирк какой-то.jbj в cooker@ также сослался на вот это сообщение Корявова (kda) с предложением работы по RPM5: https://www.opennet.ru/openforum/vsluhforumID3/76875.html#142
И тут мне сообщают, что Комиссаров в facebook пишет Казанцеву (akdengi) следующее:
---
Dmitry написал: Вот интересно Александр а зачем Вы то задаете это вопрос ?
Мало того что Джеффу мосье Шигорин ссылки присылвет на перевод статей с
недостоверной информацией, после чего в рассылке инженерной ему приходится
разьяснять контекст и участников.
---Самое смешное в этом то, что Джеффу я и не думал слать ссылку на русскоязычный сайт (да и вообще как-либо жаловаться). А вот что думал -- так это прибить коммерческое объявление в непрофильном разделе, но решил, что конкретно моей рукой это будет неуместно. И не прибил. Вот как Джефф на него напоролся -- самому интересно.
Выводы предлагаю делать самостоятельно.
> в рассылке инженерной ему приходится
> разьяснять контекст и участников.И как они справились с этим?
>> в рассылке инженерной ему приходится
>> разьяснять контекст и участников.
> И как они справились с этим?(пожимая плечами) Думаю, опять не справились. Но это всего лишь предположение.
А контексты -- штука тонкая. Особенно когда врущий судит по себе того, кто врать не привык.
PS: сделал http://ftp.linux.kiev.ua/pub/Linux/Mageia/ и после выхода релиза думаю снести ../Mandriva как неактуальное и неподдерживаемое. Лучше тех мужиков лишним гигабитом подопру.
>>> в рассылке инженерной ему приходится
>>> разьяснять контекст и участников.
>> И как они справились с этим?
> (пожимая плечами) Думаю, опять не справились. Но это всего лишь предположение.
> А контексты -- штука тонкая. Особенно когда врущий судит по себе
> того, кто врать не привык.
> PS: сделал http://ftp.linux.kiev.ua/pub/Linux/Mageia/ и после выхода релиза думаю снести
> ../Mandriva как неактуальное и неподдерживаемое. Лучше тех мужиков лишним гигабитом
> подопру.Похоже, Джефф полностью отказался от поддержки RPM5:
And my lazy scmuck sysadmin has now restarted httpd.
You've had *MONTHS* to make peace with rpm5, now y'all have
your very own rpm5.org "project" to participate in or trash mouth as you wish.Have fun!
Thierry: And you alone were responsible for destroying the "rpm5" brand.
Посмотрел на днях бету Rosa Desktop. Это не LiveCD, а просто CD, неживой. Так что хорошо, что эти люди хотя бы отложили релиз Mandriva -- глядишь, разработчики из кожи вон вылезут, но хоть белыми нитками заштопают...