Опубликован (http://dnf.baseurl.org/2016/12/20/dnf-2-0-0-and-dnf-plugins-.../) второй значительный релиз пакетного менеджера DNF (http://dnf.readthedocs.org/en/latest/release_notes.html) (2.0), который вобрал в себя улучшения, подготовленные после задействования DNF по умолчанию в Fedora Linux и сосредоточенный на улучшении совместимости с YUM.
В DNF 2.0 реализованы более понятные уведомления о проблемах с зависимостями, организован показ списка слабых зависимостей в суммарных параметрах транзакции, добавлена улучшенная система подсказки для доступных команд. В основной состав DNF перемещён плагин Repoquery (https://dnf.readthedocs.io/en/latest/command_ref.html#repoqu...). Добавлены новые unit-файлы дляw systemd: dnf-automatic-notifyonly, dnf-automatic-download и dnf-automatic-download.
Реализованы команды и опции:
- "dnf remove --duplicates" и "dnf remove --oldinstallonly" для удаления старых версий для дублирующих друг друга пакетов и старых пакетов категории installonly.
- "dnf repoquery" - для поиска пакетов во внешних репозиториях (аналог "rpm -q" для удалённого репозитория);
- Добавлена опция "--repo репозиторий" для ограничения операций только репозиторием, выбранным по идентификатору или маске.
- Новые команды "dnf check" и "dnf upgrade-minimal".
- Новые опции для выбора уровня безопасности: bugfix, enhancement, newpackage, security, advisory, bzs, cves, sec-severity и secseverity.
К сожалению, некоторые особенности выпуска, связанные с поддержкой особенностей работы с YUM, привели к нарушению (http://dnf.readthedocs.io/en/latest/dnf-1_vs_dnf-2.html) полной совместимости с веткой DNF-1. В том числе возвращено свойственное для YUM поведение для настроек файла конфигурации, например опции "include" и "exclude" заменены на "includepkgs" и "excludepkgs", для установки опциональных зависимостей вместо команды "with-optional" теперь предлагается параметр "--with-optional", вместо
"dnf search all" - "dnf search --all", "dnf makecache timer" - "dnf makecache --timer", вместо "dnf list command" - "dnf list --command", вместо "dnf repolist [enabled|disabled|all]" - "dnf repolist [--enabled|--disabled|--all]" и т.д. Также изменены аргументы в некоторых вызовах Python API.
Напомним, что DNF является ответвлением от Yum 3.4, созданным для развития некоторых новых идей, таких как использование библиотеки hawkey (https://github.com/rpm-software-management/hawkey) в качестве бэкенда для разрешения зависимостей. В качестве основных проблем Yum, которые побудили к созданию DNF, называют некачественную документацию на API, проблемный алгоритм разрешения зависимостей и невозможность рефакторинга внутренних функций. По сравнению с Yum, DNF обладает заметно более высокой скоростью работы, низким потреблением памяти и более качественным управлением зависимостями. Кроме того, DNF может выполняться как при помощи Python 2, так и Python 3, что позволило реализовать план по поставке Python 3 в Fedora по умолчанию.
Для разрешения зависимостей в DNF задействован SAT solver, реализованный в библиотеке libsolv (https://github.com/openSUSE/libsolv) (hawkey выступает в роли надстройки над libsolv), созданной в рамках проекта openSUSE. Обработки метаданных и загрузка пакетов выполняется через librepo (https://github.com/tojaj/librepo). Для расширения функциональности DNF предоставляет новый, не совместимый с Yum, API для плагинов и интеграции с другими приложениями, такими как инсталлятор Anaconda. На уровне опций командной строки и файлов конфигурации, DNF почти полностью совместим с YUM.URL: http://dnf.baseurl.org/2016/12/20/dnf-2-0-0-and-dnf-plugins-.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=45730
Кто-нибудь знает, CentOS/RHEL перейдет на это?
CentOS перейдёт, скорее всего. REHL только когда оттестируют на федоре.
Конечно. В следующем мажорном релизе.
Конечно, оно изначально для грядущего RHEL 8 и разрабатывалось.
Rhel строится из fedora.
правильно - обкатать на хомячках баги - и продать их работу за бабло.
Поэтому господа сидят на Арче.
Я тебя удивлю, но арчеводы являются тестерами почти для всех пакетов;)
При этом у нас проблемы фиксятся на момент фикшенья апстримом, т.е. за считанные часы или дни с случае серьёзных грабель. А в стабильных ЦентОсах и Дебльянах по нескольку лет с одними и теми же багами сидят, причём иногда очень жирными. Знаем, плавали...
Centos и debian называются стабильными не потому что в них нет багов, а потому что в них не происходит изменений. Серьёзными являются баги безопасности и они фиксятся.
В обсуждении речь шла о том кто больший тестер пакетов - юзеры федоры или юзеры арча. Но никто не отрицает что обе группы являются таковыми. Мне нравится идеология арча, но не нравится его недостаточая стабильность при этом. Сейчас сижу на manjaro за счет дополнительного тестирования пакетов дистрибутив достаточно стабилен и при этом идеология арча сохранена.
на gentoo же
неплох, но слишком зависим от апстрима (патчи не делают относительно). За времен kernel < 3.6 было все еще хорошо, последний раз смотрел - с gtk3 проблемы с рендерингом, nm-плагины разваливаются, kf5 вообще не пригоден
> Добавлены новые unit-файлы для systemd: dnf-automatic-notifyonly, dnf-automatic-download и dnf-automatic-download.для systemd надо 2 unit'a для download.. по другому никак
> New systemd units dnf-automatic-notifyonly, dnf-automatic-download, dnf-automatic-download were added for a better customizability of dnf-automatic.Забавно, что и в оригинале так же.
"dnf-automatic-notifyonly, dnf-automatic-download, dnf-automatic-install" http://dnf.readthedocs.io/en/latest/automatic.html
Помоему второе dnf-automatic-download не относится уже к самому перечислению, а является пояснением что это такое за dnf-automatic-download.
А без systemd мейнтенеру надо писать скрипты. По-другому никак.
yum-updatesd?
Что yum-updatesd? А как он по твоему вызываться будет?
мисье о Cron знает ?
> мисье о Cron знает ?https://imgur.com/gallery/D1XK8nk
> В том числе возвращено свойственное для YUM поведение для настроек файла конфигурации, например опции "include" и "exclude" заменены на "includepkgs" и "excludepkgs"Поясните, ведь в yum есть опции inclue/exclude, зачем нужны includepkgs/excludepkgs "для совместимости"?
В yum есть exclude и includepkgs, в dnf-1 - include и exclude, в dnf-2 - includepkgs, excludepkgs и exclude=excludepkgs.
Явно готовятся к интеграции в очередной rhel
Не прошло и ста лет пока не отказались от Python версии пакетного менеджера. Надеюсь dnf то хоть на Си писан?
> Не прошло и ста лет пока не отказались от Python версии пакетного менеджера. Надеюсь dnf то хоть на Си писан?Нет. На python 3
зачем менять yum???!!! ну скажите мне зачем?
Зачем слезать с деревьев? Действительно. К черту прогресс.
> зачем менять yum???!!! ну скажите мне зачем?DNF веселее YUM.
в заметке же написано какие проблемы решали при разработке DNF, кажется даже по-русски.
> зачем менять yum???!!! ну скажите мне зачем?yum очень топорно и тупо в лоб строил дерево зависимосией, а при проблемах в нем начинал перестраивать его итеративно по нескольку раз. В итоге обновление тысячи пакетов при одной битой зависимости могло вылиться в часовой пересчет дерева. dnf же использует satsolver и любое дерево обсчитывает за секунды/десятки секунд. Т.е. поддерживаемость сорцов yum оказалась низкой, получилось проще переписать его, чем внедрить satsolver в существующий код.
Хотя бы потому, что оно жрет память сотнями мегабайт и на контейнерах с <512MB нередко становится нерабочим. Но даже при достаточной памяти оно может настолько долго думать, что приходится самостоятельно разбивать действия на элементарные и скармливать ему по частям или вообще напрямую с rpm возится.
Мозги бы им лучше поменять, а то с каждым новым индусом новый пакетный менеджер будет появляться, никто блять не хочет думать архитектурно и основательно, строили бы так дома как пилят ПО, вызывает отвращение с точки зрения искусства
С точки зрения искусства, мазня ван Гога -- шедевр. В чёрту искусство.
мазня ван гога не есть архитектурное проектирование, где важна математическая точность, (искусство тут имелось в смысле математической (геометрической) точности и изящества)
зачем менять юм? пепельница забилась, в каментах выше раскрыли тему
Кто объяснит почему eopkg из SolusOS и pacman из Arch такие быстрые, а dnf и apt намного медленнее их? Ну в плане скорости установки обновлений и так далее. В чём такая колоссальная разница скорости?
есть еще emerge, который тоже не быстрый.
Быстрота emarge сильно зависит от того, насколько сильно кастомизируются use-флаги и используется смешивание веток.
apt сам по себе шустрый, тормозит dpkg. Получается забавная ситуация, в debian-based быстрый apt и тормознутый dpkg, а в rhel-based тормознутый yum и шустрый rpm.
да, pacman >= 5.0 уже не тот (archlinux). rpm5 ничем не быстрее rpm4 (визуально). Остается попробовать "гибрид" backend rpm + frontend apt (тот, что в альте)
Именно поэтому я пользуясь Альтом с его apt-rpm.
наверное, потому что мейнстрим-хомячки должны страдать от стабильности.
Есть где-нибудь сравнение производительности DNF и YUM?
Тебе зачем? если yum скоро никто поддерживать не будет? везде останется dnf
Жри что дают и не задавай вопросов?Если производительнее, то насколько? А то если это пол процента, то нафиг такие переходы.
Потратить один раз пять минут и переучиться будет быстрее, чем многократно тратить часы и дни на самостоятельную поддержку yum в новых дистрибутивах, и потом радоваться, что все работает как было, и не надо переучиваться. Пока что-нибудь не сломается, тогда надо снова лезть и ковыряться. А потом снова. По мне так оно того не стоит. Хотя осознание приходит далеко не сразу.
Да ноу проблем. У меня только CentOS. Интересно когда ждать. К 2019-му? )
> Да ноу проблем. У меня только CentOS. Интересно когда ждать. К 2019-му?
> )Ну когда будет, тогда и будет. Мой комментарий больше относился к любителям поставить yum на новые версии Федоры. А такие есть.
О чём вы говорите?
Там кого-то заботят ваши проблемы, думаете?
Они даже nmcli поломали зачем-то. В новой шапке (7.3) опции работают по-другому.
Спрашивается: ЗАЧЕМ?!
> Жри что дают и не задавай вопросов?Нет, не так. "Жри что дают и учи уроки".
Производительнее в сотни раз, что особенно заметно при обновлении большого количества пакетов. dnf при этом является форком yum-а, только основательно переписанным.
И часто вы на серверах большое количество пакетов обновляете?
>Добавлены новые unit-файлы для systemd: dnf-automatic-notifyonly, dnf-automatic-download и dnf-automatic-download.Что-то я туплю, кажется.
А где те крикуны, которые заявляли, что на питоне плохо писать нельзя?
> А где те крикуны, которые заявляли, что на питоне плохо писать нельзя?Плохо ни на чем нельзя писать. Стыдно должно быть писать плохо
Стыдно делать ошибки, когда говоришь или пишешь на русском языке. А эти умники хотят еще на Python писать правильно.И если в голове каша - то и получаем ****мо на любом языке.
научился делать autoremove "сирот" ? fc22-23 было поломано
> научился делать autoremove "сирот" ? fc22-23 было поломаноДа, в 2.0 автоматически удаляет нетребуемые никем зависимости, как при yum remove --remove-leaves.
Нет уж, лучше старый добрый yum нежели эта поделка.
yum просто работает и делает то, что от него ждешь, а чем занимается dnf мне не понятно.
Угумс, разворачиваем кэширующую днску на центосе с гигом оперативы, отдаем по максимуму под кэш - радуемся, потом делаем юм апдейт, пару часов ждем пока ядро пытается свопить, а потом плачем по убитому оомкиллиром процессу. Можно конечно добить оперативы, но это резервирование конкретно под юм получатся, ни для чего другого она использоваться не будет.
> Угумс, разворачиваем кэширующую днску на центосе с гигом оперативы, отдаем по максимуму
> под кэш - радуемся, потом делаем юм апдейт, пару часов ждем
> пока ядро пытается свопить, а потом плачем по убитому оомкиллиром процессу.
> Можно конечно добить оперативы, но это резервирование конкретно под юм получатся,
> ни для чего другого она использоваться не будет.В конкретно данном случае виновато ваше неумение пользоваться системой, а не юм.
Не обновляйте все пакеты разом и будет вам счастье.
Это не Apple-way. Все должно работать быстро, не занимать память и вести себя предсказуемо, исполняя основную задачу. А если у вас при использовании yum оперативки не хватило, место на HDD закончилось или проц перегрелся - это означает, что yum кривой, а не то, что я им пользоваться не умею.
> В конкретно данном случае виновато ваше неумение пользоваться системой, а не юм.Глупости
> Не обновляйте все пакеты разом и будет вам счастье.
Будешь апгрейдить систему - приходи, расскажешь как это тебе удалось