интересные графики сравнения производительности (deb vs rpm)

[sash-kan]

http://www.linux-mag.com/id/7382/
текст можно и не читать (я не читал).
всё видно по картинкам.

вентилятор включен, вброс произведён. (улыбка)
ваш ответ, сторонники rpm!

[/dev/random]

А у RPM есть сторонники? Я думал, пользователи RPM-based дистров используют их вовсе не из-за формата пакетов. Ну а то, что yum - тормозилище, я думал, каждой собаке известно.

[mandrivauser]

Работала бы Urmpi по-стабильнее да зависимости по-лучше бы смотрела... А так мне все равно

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

[Rootlexx]

ваш ответ, сторонники rpm!

Я хоть и не сторонник RPM, но тем не менее, эти тесты никак не относятся непосредственно к DEB или RPM. Там сравнивается APT и Yum. Это совершенно другое.
По своему опыту общения с RPM-дистрибутивами могу выделить в RPM три плюса:

• более быстрая установка пакетов — да-да-да, именно: если сравнивать непосредственно работу утилит dpkg и rpm, установка RPM-пакетов занимает меньше времени;
• сжатие LZMA — пакеты занимают меньший объём, значит, меньше трафик;
• DeltaRPM, как в последней Fedora и openSUSE — не слышал о таком в Debian/Ubuntu.

Тем не менее, в DEB есть свои плюсы, основной из которых — гибкость.
Теперь снова почему этот тест некорректен: Yum используется среди более-менее популярных дистрибутивов только в Fedora. В openSUSE Zypper, в Mandriva URPMI, есть и порт APT для работы с RPM (в ALTLinux, PCLinuxOS). Так что делать из этих тестов выводы о превосходстве DEB над RPM смешно.

[Bluetooth]

http://www.linux-mag.com/id/7382/
текст можно и не читать (я не читал).
всё видно по картинкам.

вентилятор включен, вброс произведён. (улыбка)
ваш ответ, сторонники rpm!

Честно говоря, ожидал сравнения производительности пакетного менеджера rpm с dpkg(или как он у вас там зовется), тогда это будет похоже на сравнение rmp-deb. А тут я вижу сравнение apt(верно?) и yum. А это никак не похоже на сравнение rpm - deb.
Они бы еще с zypper старых версий сравнили бы(кстати, zypper новых версий, на мой взгляд, довольно быстрый )

[sash-kan]

deb и rpm — это условные обозначения.
сравнивать dpkg и rpm (который бинарник) — imho, бессмысленно. слишком разные принципы работы.
а вот сравнение aptitude и yum|zypper|urpm|etc — это уже ближе к телу. принципы работы и вообще глобальный смысл у них схож.

ну что ж, продолжим святые вентиляторные войны?

вот тут недавно столкнулся с очередным мандробагом как правильно установить пакет?
и по мотивам родился вопросец к знатокам чего-нибудь из yum|zypper|urpm|etc:

1. пакет А зависит от Б или В.
2. Б и В конфликтуют друг с другом.
3. Б и В зависят от А
4. если сказать менеджеру «установи А», установятся А и Б
5. можно сказать менеджеру «установи А и В»
6. можно сказать менеджеру «установи Б» или «установи В». автоматом установится и А
7. если установлены А и Б, и сказать менеджеру «установи В», будет попутно удалён пакет Б
8. если установлены А и Б, и сказать менеджеру «удали А», будет удалён и Б
9. если установлены А и Б, и сказать менеджеру «удали Б», будут предложены варианты решения: «удалить Б и установить В», «удалить А и Б»
все ли из перечисленных действий|состояний возможны в менеджерах yum|zypper|urpm|etc?

и второй вопросец:
в пакет входит конфигурационный файл (назовём его «версия1»)
пользователь изменил этот файл и получилась «версия2»
вышла новая версия пакета, включающая изменённый конф. файл («версия3»)
при установке этого обновления, предложит ли кто-нибудь из yum|zypper|urpm|etc просмотреть (и изменения и конечный результат) и наложить изменения «версия1->версия3» на текущий файл «версия2»? (вычисляется с помощью diff3).

и на закуску третий вопросец:
в пакет входит конфигурационный файл (версия1).
после установки он был изменён (версия2).
пакет был удалён (без удаления конф. файлов).
пакет был вновь установлен.
конфигурационный файл выглядит как версия2.
возможно ли всё это в yum|zypper|urpm|etc?

[Rootlexx]

Так как с менеджерами, отличными от URPMI, имел дело давно, о них говорить не буду. Так что вещаю как бывший Mandriv'овец.

1. пакет А зависит от Б или В

Косвенно — да. Пакет «Б» и пакет «В» предоставляют («Provides») некоторый «F», а «А» зависит от «F».

2. если сказать менеджеру «установи А», установятся А и Б

3. можно сказать менеджеру «установи А и В»

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

4. можно сказать менеджеру «установи Б» или «установи В». автоматом установится и А

Такого нет. Ну разве что если «А» не находится в рекомендуемых зависимостях для этих пакетов.

5. если установлены А и Б, и сказать менеджеру «установи В», будет попутно удалён пакет Б

Будет конфликт, но можно указать опцию замены пакета: «--replacepkgs».

6. если установлены А и Б, и сказать менеджеру «удали А», будет удалён и Б

Есть.

7. если установлены А и Б, и сказать менеджеру «удали Б», будут предложены варианты решения: «удалить Б и установить В», «удалить А и Б»

Такого нет.
Подозреваю, что всё вышеперечисленное есть в Zypper.

Добавлено:

в пакет входит конфигурационный файл (назовём его «версия1»)
пользователь изменил этот файл и получилась «версия2»
вышла новая версия пакета, включающая изменённый конф. файл («версия3»)
при установке этого обновления, предложит ли кто-нибудь из yum|zypper|urpm|etc просмотреть и наложить изменения «версия1->версия3» на текущий файл «версия2»?

URPMI не предложит, новая версия конфига будет сохранена под именем «имя.rpmnew», о чём будет выведено предупреждение.
И да, RPM предоставляет всё необходимое для реализации вышеперечисленного функционала. Так что Aptitude, конечно, штука классная, но она есть и для RPM .
И хотелось бы получить ответ на несколько моих вопросов:

• Есть ли в Aptitude/APT возможность автоматической параллельной установки пакета на несколько машин? URPMI может скачать пакет на одной машине, скопировать его по ssh на произвольные другие и установить на все одновременно, и всё это полностью автоматически.
• Так есть ли возможность DeltaDEB? То есть DEB-пакеты, которые содержат в себе бинарные различия с предыдущей версией и, соответственно, занимают намного меньше места (хотя благодаря LZMA-сжатию RPM и так менее объёмные, нежели DEB).
• Как я могу посмотреть, какие пакеты зависят от данного пакета (опция rpm «--whatrequires»)? Можно, конечно, сделать так:
  

  Код: Выделить всё

  aptitude why имя_пакета

  — и смотреть по действию «purge», но это совершенно не удобно.
• Можно ли в Debian/Ubuntu провести проверку целостности установки пакета? RPM может (наряду с обычными возможностями вроде проверки подписи):
  

  S file Size differs
  M Mode differs (includes permissions and file type)
  5 MD5 sum differs
  D Device major/minor number mismatch
  L readLink(2) path mismatch
  U User ownership differs
  G Group ownership differs
  T mTime differs

  — а также есть директива «%verifyscript», позволяющая проверить результаты действия пре/пост скриптов.
  Очень удобно проверять целостность системы:
  

  Код: Выделить всё

  rpm -Va 2> verification_failures.log

  — эта команда запустит проверку всех установленных пакетов и выведет все проваленные тесты в файл.

А вообще, советую почитать man rpm. По крайней мере не будет вопросов по возможностям самой пакетной системы, а насколько уж они реализованы в конкретных менеджерах пакетов, дело другое.

[Bluetooth]

Такого нет. Ну разве что если «А» не находится в рекомендуемых зависимостях для этих пакетов.

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

deb и rpm — это условные обозначения.
сравнивать dpkg и rpm (который бинарник) — imho, бессмысленно. слишком разные принципы работы.
а вот сравнение aptitude и yum|zypper|urpm|etc — это уже ближе к телу. принципы работы и вообще глобальный смысл у них схож.

ну что ж, продолжим святые вентиляторные войны?

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

По поводу первого класса вопросов - сказать ничего не могу. Но думаю, что zypper тут будет неплох.

и второй вопросец:
в пакет входит конфигурационный файл (назовём его «версия1»)
пользователь изменил этот файл и получилась «версия2»
вышла новая версия пакета, включающая изменённый конф. файл («версия3»)
при установке этого обновления, предложит ли кто-нибудь из yum|zypper|urpm|etc просмотреть (и изменения и конечный результат) и наложить изменения «версия1->версия3» на текущий файл «версия2»? (вычисляется с помощью diff3).

Из условия возникает вопрос - где взять версию1? ее не существует в системе на момент установки обновления. Да и вообще автоматом накладывать какие-то изменения в конфиг - идея мне не кажется здоровой. А вот поведение zypper мне кажется вполне логичным(хотя вроде это и не zypper выполняет, а rpm на более низком уровне). А именно: если в обновлении идет новая версия конфига, то он сохраняется в той же папке под именем название.rpmnew, и выводится варнинг на стандартный вывод. При стирании некоторых пакетов(особенность ли это сборки таких пакетов, или же это стандартное поведение rpm для определенного класса пакетов, сказать не могу) конфиги сохраняются в той же папке под именем название.rpmsave, и выводится варнинг.
По-моему все довольно хорошо в этом плане.
вот как-то так :)

[/dev/random]

Разбавлю сравнение третьим форматом - ебилдами.

1. пакет А зависит от Б или В.

да

2. Б и В конфликтуют друг с другом.

да

3. Б и В зависят от А

да

4. если сказать менеджеру «установи А», установятся А и Б

да

5. можно сказать менеджеру «установи А и В»

да

6. можно сказать менеджеру «установи Б» или «установи В». автоматом установится и А

да

7. если установлены А и Б, и сказать менеджеру «установи В», будет попутно удалён пакет Б

Будет предложено удалить его вручную.

8. если установлены А и Б, и сказать менеджеру «удали А», будет удалён и Б

да

9. если установлены А и Б, и сказать менеджеру «удали Б», будут предложены варианты решения: «удалить Б и установить В», «удалить А и Б»

нет

[слишком много цитат name='sash-kan' date='Jun 20 2009, в 02:06' post='885724']
и второй вопросец:
в пакет входит конфигурационный файл (назовём его «версия1»)
пользователь изменил этот файл и получилась «версия2»
вышла новая версия пакета, включающая изменённый конф. файл («версия3»)
при установке этого обновления, предложит ли кто-нибудь из yum|zypper|urpm|etc просмотреть (и изменения и конечный результат) и наложить изменения «версия1->версия3» на текущий файл «версия2»? (вычисляется с помощью diff3).
[/]да, конфиги не замещаются, вместо этого новые версии размещаются во временных файлах для обработки с помощью etc-update (или вручную)

[слишком много цитат name='sash-kan' date='Jun 20 2009, в 02:06' post='885724']
и на закуску третий вопросец:
в пакет входит конфигурационный файл (версия1).
после установки он был изменён (версия2).
пакет был удалён (без удаления конф. файлов).
пакет был вновь установлен.
конфигурационный файл выглядит как версия2.
[/] Да

[Rootlexx]

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

Файлы, которые в spec были помечены как конфигурационные, и которые были изменены после установки.

[Bluetooth]

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

Файлы, которые в spec были помечены как конфигурационные, и которые были изменены после установки.

Я подозревал об этом Спасибо, что уточнили. теперь буду знать

[/dev/random]

И вот такой вопрос: появилась ли хоть где-нибудь, кроме ебилдов (т.е., в rpm или deb) возможность деления пакетов на установленные по команде пользователя и вытянутые по зависимостям, с возможностью чистки пакетов, которые по зависимостям больше не нужны? Где-то с год назад я видел это в списке TODO urpmi, а до того нигде кроме gentoo не видел. Уже реализовали или нет?

[Rootlexx]

появилась ли хоть где-нибудь, кроме ебилдов (т.е., в rpm или deb) возможность деления пакетов на установленные по команде пользователя и вытянутые по зависимостям, с возможностью чистки пакетов, которые по зависимостям больше не нужны? Где-то с год назад я видел это в списке TODO urpmi, а до того нигде кроме gentoo не видел. Уже реализовали или нет?

Да, давно в APT/Aptitude и недавно в URPM. Насчёт других не скажу, когда тесно обращался — не было ещё.

[Olegator]

пробежимся ещё немного по zypper

Repository Index Service (RIS) is a client-server protocol for package repository management. Based on information provided by the client via URI, the server responds with an XML repository index. The client then uses this information to manage the service's repositories on the system.

Repository Index Service is an extension of Novell Update Service employed in update management of SUSE Linux Enterprise. Compared to NU services, RIS does not require authentication. The repository index can be generated based on any information contained in the URI, like URI parameters, path, as well as user credentials. Another extension allows to use whole URI in the index, while NU services only allow a path relative to the URI of the service.

есть ли такое в APT/Aptitude/URPM/yum

[Ленивая Бестолочь]

есть ли такое в APT/Aptitude/URPM/yum

честно говоря - так и не понял, зачем это.

[Olegator]

честно говоря - так и не понял, зачем это.

что-то вроде удалённого управление репозитариями

A Service in this context is a Repository Index Service (RIS) that can offer one or more software repositories. Such a Service can be changed dynamically by its administrator or vendor.

[sash-kan]

И хотелось бы получить ответ на несколько моих вопросов:
Есть ли в Aptitude/APT возможность автоматической параллельной установки пакета на несколько машин? URPMI может скачать пакет на одной машине, скопировать его по ssh на произвольные другие и установить на все одновременно, и всё это полностью автоматически.

afaik, аналогичной надстройки над apt не существует.
но функционал реализуем достаточно просто другими средствами.
чтобы избежать множественных закачек, подойдёт локальный репозиторий.
для выполнения аналогичных действий на группе машин с помощью ssh существует достаточное количество готовых решений:

Код: Выделить всё

$ apt-cache search ssh parall
...
dish - the diligence/distributed shell for parallel sysadmin
dsh - dancer's shell, or distributed shell
kanif - cluster management and administration swiss army knife
...
pssh - Parallel versions of SSH-based tools
taktuk - efficient, large scale, parallel remote execution of commands
...

Так есть ли возможность DeltaDEB? То есть DEB-пакеты, которые содержат в себе бинарные различия с предыдущей версией и, соответственно, занимают намного меньше места (хотя благодаря LZMA-сжатию RPM и так менее объёмные, нежели DEB).

принципиально пакет debdelta существует (улыбка):
http://packages.debian.org/search?keywords...amp;section=all

Как я могу посмотреть, какие пакеты зависят от данного пакета (опция rpm «--whatrequires»)? Можно, конечно, сделать так:

Код: Выделить всё

aptitude why имя_пакета

— и смотреть по действию «purge», но это совершенно не удобно.

$ apt-cache rdepends <пакет>

Можно ли в Debian/Ubuntu провести проверку целостности установки пакета? RPM может (наряду с обычными возможностями вроде проверки подписи):

S file Size differs
M Mode differs (includes permissions and file type)
5 MD5 sum differs
D Device major/minor number mismatch
L readLink(2) path mismatch
U User ownership differs
G Group ownership differs
T mTime differs

— а также есть директива «%verifyscript», позволяющая проверить результаты действия пре/пост скриптов.
Очень удобно проверять целостность системы:

Код: Выделить всё

rpm -Va 2> verification_failures.log

— эта команда запустит проверку всех установленных пакетов и выведет все проваленные тесты в файл.

это уже точно к пакетным менеджерам не имеет отношения.
но поиск рулит: Получить список изменившихся файлов пакета
upd. кстати, именно для этого действия предназначен целый пакет debsums.

А вообще, советую почитать man rpm. По крайней мере не будет вопросов по возможностям самой пакетной системы, а насколько уж они реализованы в конкретных менеджерах пакетов, дело другое.

спасибо, тут как бы речь именно про пакетные менеджеры.

[sash-kan]

Из условия возникает вопрос - где взять версию1? ее не существует в системе на момент установки обновления.

существует.
$ ls /var/lib/dpkg/info/*.config
вообще каталог /var/lib/dpkg/info/ — весьма интересное место.

Да и вообще автоматом накладывать какие-то изменения в конфиг - идея мне не кажется здоровой.

про автомат нет и речи. конечно, человек должен выбрать то, что требуется. причём выбирать при этом есть из чего. по памяти: отложить на потом, заменить новым конф.файлом, оставить существующий, просмотреть и отредактировать изменения прямо сейчас, и ещё какие-то варианты.

что-то вроде удалённого управление репозитариями

честно говоря, понятнее не стало. наводящие вопросы: в чём глобальный смысл «управления» через uri? в чём заключается собственно «управление» в этом случае?

[Rootlexx]

но функционал реализуем достаточно просто другими средствами.

Так и твои вопросы «реализуемы достаточно просто другими средствами». Скажем, для конфликта пакетов «Б» и «В» можно удалить первый, не обращая внимания на зависимости, а затем установить второй. Это тоже решение.

это уже точно к пакетным менеджерам не имеет отношения.

Ещё как имеет, ведь вся эта информация хранится в базе rpm. Кроме того, система управления пакетами должна уметь проверять корректность установки пакета.

но поиск рулит: Получить список изменившихся файлов пакета

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

спасибо, тут как бы речь именно про пакетные менеджеры.

Тем не менее, достижимый максимум функционала этих пакетных менеджеров заключён именно в возможностях базовых утилит управления пакетами, как dpkg и rpm.
И повторяю ещё раз: APT/Aptitude есть и для RPM!

принципиально пакет debdelta существует

А репозитории для него есть? Много что существует: движок Finereader для Linux, файловая система Reiser4 и, говорят, безглючный Windows, но если что-то не доступно для использования, можно считать, что этого нет.

Добавлено: я не отрицаю, что Aptitude — замечательный пакетный менеджер с превосходной обработкой зависимостей, но если рассматривать непосредственно RPM и DEB, получим, что у первых есть удобные и нужные вещи, которых нет во вторых, и наоборот, так что никакого особого преимущества у DEB нет.

[Rootlexx]

$ apt-cache rdepends <пакет>

Это не совсем то. «--whatrequires» показывает, какие из установленных пакетов зависят от данного, а приведённая тобой команда показывает в том числе и неустановленные пакеты. Можно, конечно, пройтись по каждому пакету из списка и проверить факт установки, но хотелось бы обойтись без написания скриптов.

[sash-kan]

Можно ли в Debian/Ubuntu провести проверку целостности установки пакета? RPM может (наряду с обычными возможностями вроде проверки подписи):

вообще данный функциоанал в debian не надстроен над системой управления пакетами.
а реализуется отдельными решениями. на вскидку:
aide debsums fcheck integrit samhain stealth tripwire

[sash-kan]

$ apt-cache rdepends <пакет>

Это не совсем то. «--whatrequires» показывает, какие из установленных пакетов зависят от данного, а приведённая тобой команда показывает в том числе и неустановленные пакеты. Можно, конечно, пройтись по каждому пакету из списка и проверить факт установки, но хотелось бы обойтись без написания скриптов.

см. w3m /usr/share/doc/aptitude/html/en/ch02s03s05.html на предмет ~D
можно организовать поиск по любому из deptype-ов: ”depends”, ”predepends”, ”recommends”, ”suggests”, ”breaks”, ”conflicts”, or ”replaces”
например, поиск установленных (~i) пакетов, у которых в секции depends встречается pattern «openssh»:
$ aptitude search '~i?depends(openssh)'

[Rootlexx]

aptitude search '~i?depends(openssh)'

Да, это более подходит, спасибо.

[diesel]

принципиально пакет debdelta существует

А репозитории для него есть?

тут следует заметить что rpm-delta - штука такая же принципиально существующая, в той же Федоре возможность использования дельта-обновлений появилась в 11-й версии, и то не совсем понятно, насколько стабильно это работает. С debdelta я, кстати, когда-то игрался, у меня оно работало, и репозитории были, как сейчас - не знаю.

[sash-kan]

Добавлено: я не отрицаю, что Aptitude — замечательный пакетный менеджер с превосходной обработкой зависимостей, но если рассматривать непосредственно RPM и DEB, получим, что у первых есть удобные и нужные вещи, которых нет во вторых, и наоборот, так что никакого особого преимущества у DEB нет.

да, в таком ключе сравнение, действительно малоосмысленно.
сравнивать надо всю инфраструктуру работы с пакетами.
начиная с создания, сборки/пересборки, структуры репозиториев и средств взаимодействия с ними, включая мэйнтэйнерские.
вот в комплексе, afaik, до debian-овской инфраструктуры с её разнообразием и проработанностью средств не дотягивает ни одна из альтернативных пакетных систем. ну, разве что, может быть, гентовская.

upd. в этом плане есть ещё слабая надежда на suse. знатоки suse, хотя бы слегка знакомые с debian, что скажете?

[drBatty]

все ли из перечисленных действий|состояний возможны в менеджерах yum|zypper|urpm|etc?

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

про автомат нет и речи. конечно, человек должен выбрать то, что требуется. причём выбирать при этом есть из чего. по памяти: отложить на потом, заменить новым конф.файлом, оставить существующий, просмотреть и отредактировать изменения прямо сейчас, и ещё какие-то варианты.

ну старый конфиг переименовывается и администратор уведомляется(это вторая причина, почему я отключил автоматическое обновление, первая - жуткие тормоза, ещё и рандомные).

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

а rpm такое умеет? это радует...

[Rootlexx]

тут следует заметить что rpm-delta - штука такая же принципиально существующая

Довольно давно есть и работает в openSUSE, причём если в последней Fedora нужно доустанавливать пакет для включения этой возможности, то в первой так всё работает по умолчанию.

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

Ну и Zypper сюда можно причислить. Конечно, там не хватает многих полезных вещей вроде автоматического удаления лишних пакетов, оставшихся после установки по зависимостям, но в остальном менеджер неплох.
А так да, инфраструктура в Debian одна из наиболее развитых. Тем не менее, это не значит, что другие менеджеры не функциональные или неудобные, отставание уменьшается буквально с каждой новой версией, да и то состояние, в котором они находятся сейчас, уже позволяет подавляюще большую часть задач успешно решать.

а rpm такое умеет? это радует...

Да, я выше уже приводил команду для подобной проверки всех установленных пакетов:

...
RPM может (наряду с обычными возможностями вроде проверки подписи):

S file Size differs
M Mode differs (includes permissions and file type)
5 MD5 sum differs
D Device major/minor number mismatch
L readLink(2) path mismatch
U User ownership differs
G Group ownership differs
T mTime differs

— а также есть директива «%verifyscript», позволяющая проверить результаты действия пре/пост скриптов.
Очень удобно проверять целостность системы:

Код: Выделить всё

rpm -Va 2> verification_failures.log

— эта команда запустит проверку всех установленных пакетов и выведет все проваленные тесты в файл.
...

[diesel]

тут следует заметить что rpm-delta - штука такая же принципиально существующая

Довольно давно есть и работает в openSUSE, причём если в последней Fedora нужно доустанавливать пакет для включения этой возможности, то в первой так всё работает по умолчанию.

ну то есть тоже самое - в принципе, возможность есть давно, но все ею не пользуются. для системы типа SuSE, или Fedora - сравнительно маленький репозиторий, в достаточной мере четкая привязка к версии системы, достаточно большое количество обновлений в середине одной версии - штука вполне оправданная. Вполне оправданно могло бы быть для Мандривы(там такого нет, я правильно понимаю?). Мы устанавливаем вполне определнную версию системы, и в рамках этой версии получаем обновления для пакетов, и дельты получаются достаточно компактными. Возможно, что-то подобное было бы логично ввести в Убунту, или другие мелкие версияоринтерированные системы. В случае прародителя - Дебиана - в котором одним из типичных юзкейсов является мешивание веток/версий софта итп - такая схема обновлений может потерять свою привелкательность и простоту. Короче эта фича, ИМХО, скорее дистрибъютивозависимая, к системе управления пакетами отношение имеет только в плане технической возможности, а есть еще вопросы насколько это оправданно для данной отдельно взятой системы.

Кстати, в плане дельт - deb умеет, и активно этим умением пользуется, использовать дельта-обновления списка пакетов в репозитории. Работает ли это в rpm-based - не уверен, тормоза при инициализации репозиториев каждый раз при запуске пакетного менеджера достаточно ощутимые.

[drBatty]

сравнивать надо всю инфраструктуру работы с пакетами.

ага. сравнивать я не могу. во первых потому, что ничего кроме urpmi не знаю(да и её - весьма слабо). Могу только отметить чудовищную сложность этой urpmi.
на самом деле обычно рассматривают drakrpm, которая как я понял надстройка над urpmi, которая - надстройка над rpm, которая в свою очередь надстройка над реляционной базой данных. Я иногда вообще поражаюсь, как это всё ещё работает. Проблема в том, что даже базовые модули системы можно менять, и их существует несколько штук для одной системы. Кроме того, не существует нормальной документации, в моей ОС man датирован 2006м(!!!) годом. У меня правда русский мануал... но всё-же. В Сети тоже не много можно наковырять...

[Rootlexx]

сравнивать я не могу. во первых потому, что ничего кроме urpmi не знаю(да и её - весьма слабо). Могу только отметить чудовищную сложность этой urpmi.

Да, URPM, конечно, вещь в себе. Написана на Perl (в Mandriva любят Perl, достаточно вспомнить Frozen-Bubble), довольно долго её вообще не касалась рука разработчика, но в последнее время дело сдвинулось с мёртвой точки, и с каждой новой версией там происходят значительные улучшения.

в моей ОС man датирован 2006м(!!!) годом

Лично я сразу удаляю русские man после установки, но это так, к слову. Посмотрите «man urpmihowto», полезный документ.