Пусть сжатие поставят 7зип, а мне больше от них ничо не надо.

1. Революций не будет. Ломать совместимость ради экономии 5% места на диске желающих нет.

2. А ты подумал, как это скажется на времени установки пакета? Не говоря уже про время его сборки (это-то ладно, это проблема сборщика, а не юзера).

Ну 7зип сжать-то можно по разному. Стандартные опции может и дают 5%, но ведь можно прочесть краткий "man 7z", там ultra settings и это ещё не предел.

О, это было бы неплохо. Там местами такая задница! Хотя бы взять способ, каким делается локализация описаний. Да, сейчас с окончательным сдвигом на utf-8 уже не так актуально, но всё ещё показательно...

лучше чем bzip2 жмет?

Отвечаем на наименее существенную часть сообщения, как водится? Ну потестировал я тут, разница порядка 15%. Хорошо, пусть будет 30%. И чего? По-твоему ради такой разницы стоит глобально ломать совместимость в таком устоявшемся пакетном манагере? Ради чего? Это опять же если пренебречь потерями процессорного времени на распаковку и априори считать что сам p7z дополнительных проблем в будущем не принесёт.

Группа людей, которая выиграет при такой замене (несчастные диалапщики из стран третьего мира без возможности просто взять и приобрести диск) настолько никого не волнует, что ты даже представить этого не можешь. :) Но даже и они выиграют немного.

Я вот если честно ни разу не натыкался на проблемы связанные с RPM именно как способом управлением пакетами. Это я к слову о том, что некоторые считают, что, к _примеру_, deb на голову выше rpm.

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

Вот мне интересно только, в какой степени основные потребители rpm (RH и Novell) будут прислушиваться к мнению этого самого "нового сообщества"?

А что разве нельзя внедрить 7-zip без потери соместимости - оставить и то и другое и постепенно смещаться в сторону?

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

О, а расскажите как туда приштопать еще и 7z и при этом уменьшить нагрузки на канал? ;-)

Дался вам этот 7z... Вот какова доля выкачиваемых rpm-ок в общем объеме лично Вашего трафика?

> Вот мне интересно только, в какой степени основные потребители rpm (RH и Novell) будут прислушиваться к мнению этого самого "нового сообщества"?

Если учесть что Max Spevack имеет адрес <mspevack redhat com>, то это повидимому из недр самого RH. А самое главное, они будут следовать в русле LBS, a это уже в свою очередь уже расширение POSIX. To есть - стандартней не бывает :), а значит RH и Novell будут там.

> в вашем высказывании по поводу них чувствуются "имперские амбиции"

При чём тут я? Я тут знаете ли ничего не решаю. Да и у меня самого трафик платный, к слову (хотя конечно не диалап). Ну и наконец rpm я редко пользуюсь. :) Но вот те, кто что-то в этом вопросе решают, интересы этой группы людей учитывать точно не будут, вот какую мысль я хотел донести.

Вопрос был в некотором смысле риторическим... Я по ссылке ходил и читал, что мол RH, Novell, Mandriva и т.п. понимают важность, нужность, bla-bla... этого начинания. Вот только коммерческая реальность иногда сильно отличается от чаяний простых юзеров ;-)

>И чего? По-твоему ради такой разницы стоит глобально ломать совместимость в таком устоявшемся пакетном манагере?

Простите кто на ком стоял? У мну в gentoo нет rpm. Наверно система без rpm это наиболее устоявшееся решение. И не надо тыкать на msi в windows. Там это почти не применяется (ибо неудобно).

Я тебя очень поздравляю что у тебя в генту нет rpm, у меня в дебиане его тоже нет, но согласись что проект вряд ли будет развиваться в интересах тех людей, кто им не пользуется. Скорее наоборот. :) Так что твой пост не очень релевантен, скажем так. :)

> Простите кто на ком стоял?

Думаю, анонимус на почве любви к флуду. :)

Мда, как обычно правдалюбцы с лора сейчас вынесут единственное верное решение, что мол все казлы, и если раньше я в таких ситуациях вспоминал анекдот о том, что в России есть социальная прослойка всегда знающая, как правильно и верно управлять страной - журналисты, то познакомившись с лором 3 года назад я понял, что в среде ИТ тоже есть мудрецы и обитают они на лоре )))))

Задница RPM.

Да чёрт с ним, с 7-zip. Штука хорошая, спору нет, но не принципиальная, в данном случае. Сказали вот что местами с RPM "задница". Это вот в каких местах конкретно? А есть ли подобная задница в Deb? А была ли? А как её там устранили?

Кстати, почему бы анонимусу с ЛОР'а не настаивать на переводе Deb'а на 7-zip? В отличие от RPM'а у Deb'а всего несколько крупных централизованных хранилищ (APT repository и Ubuntu).

Во-во! Пусть переведут!

Основная проблема RPM -- отсутствие нестрогих зависимостей. Приходится тянуть много программ, даже если их функции не нужны. В свое время необходимость ставить вместе с почтовиком пакет для связи с Palm и Nokia навело на мысли о тщете всего сущего и отогнало и от ASP Linux, и от RPMных дистрибутивов вообще.

Средствами RPM такое спокойно обходится. Делается пакет <имя_почтовика>-palm-plugin, зависящий от <имя_почтовика> и от <тулзы_для_palm>.

То-же можно норм. делать и в случае выбора из нескольких альтернатив. Что-то вроде amarok требует amarok-engine, а amarok-xine, amarok-gstreamer и amarok-nnm предоставляют этот самый amarok-engine => необходим хотя-бы один.

Imho нечеткие зависимости не нужны.

> Краткая суть плана &#8212; организация нового сообщества вокруг проекта и для начала &#8212; расчистка его кода.

Imho можно еще добавить, что в это сообщество войдут представители RH,Novell и т.д. И что хоститься оно будет по адресу rpm.org и wiki.rpm.org .

> Делается пакет <имя_почтовика>-palm-plugin, зависящий от <имя_почтовика> и от <тулзы_для_palm>.

Ну просто наглядная демонстрация того, как делать не надо. Как я вообще должен догадаться о существовании этого второго пакета? Вот dpkg мне просто предложит его доставить при установке основного, а здесь как?

Приведу ещё один пример. Вот есть в Дебиане пакет sendmail, который suggests другой пакет - sendmail-doc. Как такое сделать в rpm? Либо вообще не прописывать никакой связи между пакетами, либо опять же городить какие-нибудь метапакеты типа sendmail-with-doc и sendmail-without-doc. :)

Imo зависимости rpm - описывают технические зависимости(не будет работать без ...), а не смысловые. Для смысловых можно использовать yum (группы).

<offtop>Не смогу продолжить обсуждение, ухожу в институт</offtop>

С yum знаком шапочно, но над dpkg тоже есть аналогичная тулза, и не одна (dselect, apt, aptitude), и все они пользуются зависимостями, прописанными в самих пакетах. Мне это представляется более логичным путём, чем держать базу "смысловых" зависимостей ещё где-то отдельно, тем более что она тогда станет зависеть от конкретного выбора утилиты уровня apt. При использовании dpkg всё, что нам надо - это сами пакеты (просто свалка файликов), а из них мы можем простой командой создать полноценный репозитарий. И лишних сущностей в дополнение к самим пакетам вводить не надо.

У меня ВОПРОЗ: 7z лучше чем bzip2 жмет?

Воистину RPM сейчас просто ужасен. И даже не формат, а сама тулза. Использовать ее UNIX-way невозможно: некоторые ошибки устанавливают exit code, некоторые нет. Иногда сообщения об ошибках пишутся в stdout, иногда нет. Почему -i не может апгрейдить пакеты? Yum идет еще дальше и доводит все это до полного маразма. Создается впечатление, что писалось это студентами.

В общем написать более-менее интелектуальный (и простой!) скрипт с использованием rpm задача та еще. А ведь это должно быть чуть ли не основным требованием к системной утилите, которой пользуются администраторы.

Да, 7zip жмет лучше и чем bzip2, и даже чем рар. Лучшего алгоритма компрессии пока нет.

>Почему -i не может апгрейдить пакеты?

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

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

Да, это самый слабый пункт в том посте, теперь ответь пожалуйста на остальные. :)

Да, был бы у отцов-прародителей РедХэта моск - то был бы именно deb, в противном же, но к сожалению - самом что ни на есть реальном случае - имеет мечто быть "сохранение совместимости с устаревшим софтом" и до самой смерти езда на древнем, тормозном и кривом паравозе.

>При использовании dpkg всё, что нам надо - это сами пакеты (просто >свалка файликов), а из них мы можем простой командой создать >полноценный репозитарий

А что мешает из папки с набором RPM сделать репозитарий командой createrepo ?

а также в сусе мона качать обновления не полными rpm пакетами, а тока патчами, что нехило экономит трафик, такого нету в редхатке

> dpkg мне просто предложит его доставить при установке основного

Справедливости ради стоит заметить, что dpkg ничего не предложит - он может или поставить пакет, или не поставить. Спрашивает apt.

>И еще, как я могу поставить несколько версий библиотек (не конфликтующих друг с другом) с одинаковым названием? Нет, я конечно понимаю, что это проблема сборщика пакетов, а не конечного пользователя, но все же? Параметр --force у rpm уже отменили ? При необходимости таким образом можно и конфликтующие ставить, только что получится неизвестно.

+1. Недавно переводил свой проект на RPM - ощутил сполна все описанные грабли.

> А что мешает из папки с набором RPM сделать репозитарий командой createrepo ?

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

>Параметр --force у rpm уже отменили ?

Если пакеты не конфликтуют, то force не нужет. Вопрос был про обновление с помощью -i

IMHO всё же установка и обновление пакета - это разные действия, и было бы неплохо их отделить. Хотя и ключик, чтобы "установить или обновить", тоже не помешает.

А вот позволять ставить пакеты разных версий с одинаковыми названиями - сомнительная идея (даже если по файлам они не пересекаются). Это только путаницу создаст, и для apt/yum, да и для тебя самого. Как потом обновлять один из этих пакетов? Да и вообще, почему бы в тех случаях, когда это действительно необходимо (разные мажорные версии, например), просто не интегрировать версию в имя (чтобы можно было поставить одновременно пакеты php4-cgi и php5-cgi, например).

>В общем написать более-менее интелектуальный (и простой!) скрипт с использованием rpm задача та еще. А ведь это должно быть чуть ли не основным требованием к системной утилите, которой пользуются администраторы.

urpmi В Мандриве ? с другими пакетными менеджерами для rpm работал только периодически, но с urpmi проблем не было.

>всё же установка и обновление пакета - это разные действия, и было бы неплохо их отделить

ну так :) rpm это может. А вот как с этим обстоят дела у конкурентов (dpkg etc.)?

>А вот позволять ставить пакеты разных версий с одинаковыми названиями - сомнительная идея (даже если по файлам они не пересекаются).

в этом никто не сомневается. Просто разные случаи бывают

Если уж заикнулись про 7-zip, то надо использовать не конеретно его, а архиватор с этим алгоритмом (lzma), но использующий тот же синтаксис,что и gzip.

http://tukaani.org/lzma/

Около полугода использую, весьма доволен.

2 Teak

Нечеткие зависимости может быть и не так уж и плохи, но rpm не имеет интерактивного режима (и он не очень то и нужен), так что предлагать их некому. А нужная функциональность вполне реализуется добавлением нескольких строчек понятного для людей текста (а не непонятных предлагаемых пакетов) в описание пакета. И совместимость при этом не ломается

dpkg тоже не имеет интерактивного интерфеса, да он и не нужен. И что реализовать это окольными путями нетрудно, я тоже не сомневаюсь (хотя лучше конечно не такими бесчеловечными, как просто писать это в описание пакета :)). Просто это нужная всем функциональность, связанная с пакетами, поддержка которой к пакетному манагеру легко и естественно добавляется. Следовательно, это должно быть.

> ну так :) rpm это может.

Так я же не говорю, что rpm во всём плох. :) Наоборот, я по этому пункту обвинений в сторону rpm человеку возразил.

> И еще, как я могу поставить несколько версий библиотек (не конфликтующих друг с другом) с одинаковым названием?

Это еще одно зло. В Debian такие пакеты как раз отличаются названием! И ты можешь иметь все версии одной библиотеки установленными с названиями: libxxx-1.0, libxxx-2.0 и т.п.

>хотя лучше конечно не такими бесчеловечными, как просто писать это в описание пакета

А в чем заключается бесчеловечность? Приблизительный вариант установки пакета

yum info xxx

смотрим что нам нужно

yum install xxx xxx-yyy

Если есть нечеткие зависимости

yum info xxx

yum install xxx

Ой, блин, а он чего-то предложил

yum info xxx-yyy (я же не знаю, что скрывается за названием пакета)

yum install xxx-yyy

И что лучше?

> urpmi В Мандриве ? с другими пакетными менеджерами для rpm работал только периодически, но с urpmi проблем не было.

Я говорю про администратора/разработчика. Когда я писал обертку для rpm/yum (а она реально нужна была в коммерческом проекте), мне приходилось выделывать такие выкрутасы, что уму непостижимо. В итоге все автоматизированно и пользователь этого не замечает, но какой ценой!

Кстати, вывод каких-либо сообщений после успешной установки пакета это не очень хорошо. Ну если только при включенном -v

>мне приходилось выделывать такие выкрутасы

ну хоть рассказали бы, в чем суть проблемы :) Если серьезно, то стоит обратиться в багзиллу rh

>некоторые считают, что, к _примеру_, deb на голову выше rpm.

Покапался я тут в DEB. Честно скажу после RPM это просто страшно.

>>7z лучше чем bzip2 жмет

Начнем с того, что 7z это не алгоритм, а оболочка архиватора. Основной алгоритм (о котором вероятно речь) LZMA. действительно жмет лучше многих остальных, но как всегда - палка о двух концах.

1) SDK предосталяемый автором - очень слабо документирован, а его структура - вызывает исключительно ненормативную лексику. 2) Для наибольшего сжатия больших данных - нужно много памяти на словарь. Очень много, даже по современным меркам. 3) Если с декомпресией все впорядке, то компресия сильно ресурсоемка и в стандартном варианте не паралелится.

Уобщем, применение его в масовых прикладухах (тем более в RPM) - пока видется мне нецелесообразным.