В Fedora 22 по умолчанию будет пакетный менеджер DNF

какие киллер-фичи у него?

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

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

Пакет DNF будет по умолчанию установлен.

Вроде, давно уже.

Давно бы перешел на него, если dnf имел общую с yum'oм историю установленных/удаленных пакетов.

какие киллер-фичи у него?

Быстрее зависимости разруливает, жрет больше памяти.

Нужно почитать.

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

Вот когда появится форк DNF тогда и буду юзать

Быстрее зависимости разруливает

А yum типа разруливает медленно и кто-то от этого страдает?

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

И никто не понимает, зачем это нужно. Эпичненько.

питон на питон? нее, спасибо.

не надо.

Новость о намерениях сделать что-то дефолтом в послеследующем релизе? fallout4all, а чего не в Толксах?

А yum типа разруливает медленно и кто-то от этого страдает?

По-моему, при использовании yum страдает любой, кто когда-нибудь видел apt.

Этот DNF очень часто падает в текущей fedora rawhide. Особенно при поиске пакетов.

закопайте не нужно apt

http://www.redhat.com/about/news/archive/2013/7/thank-you-seth-vidal

Поправка:

twosev не понимает, зачем это нужно. Эпичненько.

http://fedoraproject.org/wiki/Features/DNF#Benefit_to_Fedora

А yum типа разруливает медленно и кто-то от этого страдает?

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

Инженерам, которые разворачивают сотни виртуалок автоматически для тестирования ПО, например, не пофигу.

он на третьем пистоне, который теперь дефолтный

закопайте не нужно apt

Запятую поставить по своему усмотрению.

Какие киллер фичи могут быть у софта написанного на python?

По-моему, при использовании yum страдает любой, кто когда-нибудь видел apt.

Который не умеет игнорировать зависимости, и лучше знает какие пакеты вам нужны. А, если вы начнёте умничать, и принудительно удалять через --force-all, то при первом-же обращении к apt он вам это припомнит, и не даст ничего сделать пока вы не вернёте (или не удалите по зависимостям) всё на место.

Инженерам, которые разворачивают сотни виртуалок автоматически для тестирования ПО, например, не пофигу.

Подготовить одну ВМ и клонировать, не?

А ставить туда специфичный для каждого теста набор софта, не?

Подготовить одну ВМ и клонировать, не?

Оне не умеют.

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

Почему не systemd-softwared? Куда смотрит Лёня???

Чтобы тут не было много флуда. Вот некоторые из фич.

* более быстрый резолвинг зависимостей (библиотека libsolv на С)
* более просто писать плагины. Да и уже куча написана. https://github.com/akozumpl/dnf-plugins-core
* имеет хорошую документацию.

i_gnatenko_brain

Все это невозможно реализовать без тотального переписывания. К тому же это надо еще параллельно тестировать. Ечли 2 разных названия - проще держать в системе. Да и зачем переписанному софту иметь старое имя? Dandified Yum.

А если я расскажу на лоре о том, что есть новый стандарт. AppStream. И пора бы внедрять в приложения. Все скажут не нужно? Мол у нас есть описания в рпм/деб.

i_gnatenko_brain

Почитывал недавно рашн федору, писали про недостатки RPM-пакетов. Первая мысль - пришли новые программисты и нашли «фатальный недостаток». Но потом я перечитывал новость про RHEL 5 на ЛОРе, и в комментариях узнал что об этих недостатках известно уже давно. Поэтому желаю удачи проекту.

Который не умеет игнорировать зависимости

В отличие от Fedora в Debian и клонах есть рекомендуемые зависимости, которые можно проигнорировать, если хочется. Если же зависимость жёсткая, значит, этот пакет необходим. Так что ломать зависимости просто не нужно. (А для особо одарённых есть equivs.)

А, если вы начнёте умничать, и принудительно удалять через --force-all, то при первом-же обращении к apt он вам это припомнит, и не даст ничего сделать пока вы не вернёте (или не удалите по зависимостям) всё на место.

Задача менеджера пакетов - поддерживать пакетную систему в согласованном состоянии. Так что такое поведение абсолютно корректно.

А, если вы начнёте умничать, и принудительно удалять через --force-all, то при первом-же обращении к apt он вам это припомнит, и не даст ничего сделать пока вы не вернёте (или не удалите по зависимостям) всё на место.

Задача менеджера пакетов - поддерживать пакетную систему в согласованном состоянии. Так что такое поведение абсолютно корректно.

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

Да здравствует NIH! Релиз RHEL7 состоялся, так что ближайшие 3-4 года сообщество федоры может снова начинать активно переписывать системные компоненты.

По-моему, при использовании yum страдает любой, кто когда-нибудь видел apt.

Ровно наоборот.

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

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

Если же зависимость жёсткая, значит, этот пакет необходим. Так что ломать зависимости просто не нужно.

Это вам так кажется. Вот к примеру возьмём Ubuntu (самый наверное выдающийся по части идиотских зависимостей) дистрибутив. Очень мне мешает прибитый гвоздями ibus. Мало того, что он мне просто не нужен, так он ещё и перебивает некоторые вещи связанные с раскладками. Желаю я его к примеру удалить, просто удалить и всё, без всяких оговорок, т.к. я не вижу ни одной причины по которой он должен быть оставлен. Набираю я:

# apt-get purge ibus
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  cups-pk-helper gnome-control-center gnome-control-center-data gnome-control-center-shared-data libgnome-control-center1 libgoa-backend-1.0-1 mousetweaks python-cupshelpers
  system-config-printer-common system-config-printer-gnome system-config-printer-udev
Suggested packages:
  gstreamer0.10-pulseaudio
The following packages will be REMOVED:
  ibus* unity-control-center*
The following NEW packages will be installed:
  cups-pk-helper gnome-control-center gnome-control-center-data gnome-control-center-shared-data libgnome-control-center1 libgoa-backend-1.0-1 mousetweaks python-cupshelpers
  system-config-printer-common system-config-printer-gnome system-config-printer-udev
0 upgraded, 11 newly installed, 2 to remove and 188 not upgraded.
Need to get 2 458 kB of archives.
After this operation, 9 972 kB of additional disk space will be used.
Do you want to continue? [Y/n] 

(А для особо одарённых есть equivs.)

Это «особо одарённые» его придумали, которые прадлагают заменять идиотские зависимости пустышками, вместо того, чтобы просто добавить в ПМ опцию «игнорировать», (есть наверное практически везде, кроме deb-based).

Хвалить apt вообще может только тот, кто ни с yum, ни c apt вплотную не работал и потому из всех критериев для сравнения знает только время скачивания метаданных (которое в yum тоже можно отключить).

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

Я с этим и не спорю.

Moonshine, что скажешь?

Апт умеет history undo?

Вопрос: как в apt получить имя пакета (из репа, а не только из установленных), в котором содержится бинарь, матчащийся заданной маской?

Принципиально новый велосипед, теперь с треугольными колёсами. Интересно, чем их yum не устраивает? Работает же отлично, ничего не тормозит, функционал на высоте...

Вопрос: как в apt получить имя пакета (из репа, а не только из установленных), в котором содержится бинарь, матчащийся заданной маской?

Ты меня экзаменуешь или правда не знаешь? Ответ — в 3 команды, первая из которых устанавливает доп. утилиту. Для сравнения, в yum это одна команда — yum provides pattern.

Интересно, чем их yum не устраивает?

название плохо рифмуется с их новой системой сборки COPR

Извиняюсь, перепутал направление ваших поредпочтений. Мне тоже больше нравится, как в yum сделано. А что именно там за дополнительная утилита?

Извиняюсь, перепутал направление ваших поредпочтений.

OK. И давай на ты, угу?

А что именно там за дополнительная утилита?

apt-file

По-моему, при использовании yum страдает любой, кто когда-нибудь видел apt.

я смотрю, у тебя-то с аптом всё шоколадно, да.

Нет. В какой-то мере это восполняется возможностями autoremove, но только в какой-то мере.

У меня сейчас беда с аналогами yumdownloader ещё. То есть с их отсутствием.

Чтобы скачать пакеты с зависимостями из нестандартных репозиториев, в RPM-мире достаточно использовать yumdownloader -c another_yum.conf. Что приходится делать в deb — это просто уму непостижимо.

я смотрю, у тебя-то с аптом всё шоколадно, да.

По ссылке проблема с aptitude.

Который не умеет игнорировать зависимости

Всю жизнь игнорил зависимости в apt и успешно удалял.

поддерево зависимостей

Граф зависимостей не является деревом, ибо допускает циклы.

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

Это только на словах просто, типа «надо делать хорошо и не делать плохо». Полностью игнорировать «сломанную» компоненту связности не получится, ибо, например, возможна такая ситуация:

• Вы запросили установку пакета.
• Этог пакет зависит от пакета, находящегося в «сломанном» подграфе.

Корректно разрешить такие ситуации нельзя, можно лишь сразу заворачивать любые попытки связи со «сломанным» подграфом, но учитывая большое количество возможных связей (помимо традиционных Depends и Recommends это и Breaks, и Conflicts, и Pre-Depends, и Replaces, и Provides...), подобное усложнение алгоритма приведёт к мизерной выгоде.

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

Есть и ещё подсистемы, работающие в условиях предположения о корректности состояния пакетов.

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