RPM 4.10

когда на RPM 5 , как в мандриве, перейдут?

Зачем это им нужно?

добавлена опция -e, позволяющая отображать прогресс операций установки/удаления, также доступны -h/--hash и --percent;

Вообще неверно переведено.

Erasure progress reporting added, -h/--hash and --percent are accepted on rpm -e too

когда на RPM 5 , как в мандриве, перейдут?

Там ненадежный апстрим. Не перейдут никогда.

я уже не могу поправить

«добавлено отображение прогресса операций установки/удаления, -h/--hash и --percent так же совместимы с rpm -e»

Так лучше?

RPM 5, ЕМНИП, не совместим с LSB => никогда. А зачем?

Вопрос на этот счёт решается.

Почти. Для установки все эти возможности и раньше были - теперь их добавили для удаления (которое и есть rpm -e).

«добавлено отображение прогресса операции удаления, -h/--hash и --percent могут так же использоваться с rpm -e»

измененных во время транзанкции;

Поправьте.

По теме: ну что, хорошо, в общем.

RPM5 ― это не эволюция RPM, а скорее форк. Да, с названием некрасиво получилось: могли бы и каким-нибудь yarpm'ом назвать, что ли.

автоматическая перезагрузка политик SELinux, измененных во время транзанкции;

мне кажется, что это не очень хорошо.

RPM5 ― это не эволюция RPM, а скорее форк.

Кстати, а какая реализация по-ближе к спецификации LSB - референсная?

Да, с названием некрасиво получилось: могли бы и каким-нибудь yarpm'ом назвать, что ли.

Адекватные дистростроители так и сделают :)

поддержка символа тильды (~) в версии в стиле DPKG

о! а то по привычке я пишу, а оно не работает

Не нужно. Очередной велосипед.

поддержка символа тильды (~) в версии в стиле DPKG

Осталось перейти на пакетный менеджер в стиле Debian.

Кстати, а какая реализация по-ближе к спецификации LSB - референсная?

Пишут, что в RPM5 как фичей заявили несовместимость с LSB.

Скоро так и сделают :).

Кстати, а какая реализация по-ближе к спецификации LSB - референсная?

Этот вопрос явно должен был быть задан не мне :)

Основные улучшения: ....

А шо, оно не умело даже этого? Во дела.

-h/--hash и --percent также совместимы с rpm -e;

Черте сколько лет ждал.

Крутая фича, да.

нет, спасибо, назад в каменный век нам не хочется

Да там со всем нехорошо получилось. Сайт их почитай.

Кстати, а какая реализация по-ближе к спецификации LSB - референсная?

Та, о которой речь в новости, совместима с LSB на 100%.

Дык я именно это и говорю, что нехорошо :)

Это не новость. Уже столько лет остаюсь верен deb.

используемого в RHEL (включая производные проекты: CentOS, Scientific Linux, AsiaLinux, Red Flag Linux, Oracle Linux), Fedora, SUSE, openSUSE, PLD Linux, ALT Linux, Mageia и MeeGo.

МСВС добавь :)

Нет там каменного века, они уже давно более-менее на одном уровне.

нет, спасибо, вперед в каменный век нам не хочется

fixed

Минорнота же. По смыслу.

автоматическая перезагрузка политик SELinux, измененных во время транзанкции;

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

когда на RPM 5 , как в мандриве, перейдут?

Несколько я знаю, RPM 5 это форк.

Ну конечно. Например, как там с файловыми зависимотями в dpkg?

Нафига они вообще нужны, если нормально прописаны зависимости по пакетам?

«Нормально» это так как в дебе чтоль? Когда обновляется минорная версия либа без смены ABI, а все вновь собранные пакеты автоматом на неё завязываются? Нет, спасибо, я считаю, что это не нормально.

не нуно

Так же, как и со спек файлами в RPM, которые в случае если надо сделать что-то вменяемое, например разделить библиотеку и документацию к ней, становятся похожи на коричневую массу и это не шоколад.

В dpkg сейчас же все удобно и шоколадно.

Так же, как и со спек файлами в RPM, которые в случае если надо сделать что-то вменяемое, например разделить библиотеку и документацию к ней, становятся похожи на коричневую массу и это не шоколад.

В dpkg сейчас же все удобно и шоколадно.

Объясни, каким местом разделение библиотеки и документации в дебиане легче, чем в rpm?

И что в rpm такого сложного? Добавить описание для пакета с документацией и разделить список файлов на две части - это сложно?

если нормально прописаны зависимости по пакетам?

Зависимости по пакетам действуют только в рамках одного дистрибутива и то, часто, в рамках только одного релиза. А благодаря файловым зависимостям, я могу поставить пакет от Федоры на openSUSE и все зависимости подтянутся правильно.

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

бред какойто, сказал deb =)

Учите матчасть, man dpkg-shlibdeps

Учите матчасть, man dpkg-shlibdeps

Это действует только для текущего релиза. Для другого релиза пакет придется пересобирать, как Reset и сказал.

А мне вот арчевские пакеты нравятся. Практически чистый баш, никакой ***ли с макросами, с debhelper'ом, с сотней файликов в debian/, с нескучным форматом патчей.

Да, кое чего нет, вроде упомянутых зависимостей от файла либы. Но это отсутствие намного упрощает пакетную систему.

Нет, ты всё-таки учи матчасть.

Объясни, каким местом разделение библиотеки и документации в дебиане легче, чем в rpm?

Spec файл похож на портянку.

И что в rpm такого сложного? Добавить описание для пакета с документацией и разделить список файлов на две части - это сложно?

Ничего. Просто в deb-пакетах это удобнее.

ога, которая привяжет мне пакет к текущим пакетам с либами, о чем я и сказал

Блджад! Носом ткну — http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps

Сидите на своём RPM и ничего не видите вокруг.

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

Еще один неосилятор builddeps.