The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск пакетного менеджера DNF 4.6

29.01.2021 10:50

Доступен релиз пакетного менеджера DNF 4.6, который используется по умолчанию в дистрибутивах Fedora Linux и RHEL 8. DNF является ответвлением от Yum 3.4, адаптированным для работы с Python 3 и использующим библиотеку hawkey в качестве бэкенда для разрешения зависимостей. По сравнению с Yum, DNF обладает заметно более высокой скоростью работы, низким потреблением памяти и более качественным управлением зависимостями.

В новой версии в операциях отката истории изменений (redo, rollback и undo) добавлена поддержка "comps", файла с метаданными для разбивки пакетов на функциональные группы. В директиву filter_modules добавлена опция для отсеивания устаревших версий на основе параметра module_obsoletes. В логе dnf.log обеспечено отражение пакетов, установленных или удалённых через DNF API. В API добавлены функции для загрузки кэша репозитория.

  1. Главная ссылка к новости (https://github.com/rpm-softwar...)
  2. OpenNews: Началась разработка пакетного менеджера DNF 5 и замены PackageKit
  3. OpenNews: В DNF предлагают встроить UUID для идентификации установок Fedora
  4. OpenNews: Дистрибутив OpenMandriva переходит на RPMv4 и DNF
  5. OpenNews: Пакетный менеджер DNF будет переработан на языке Си
  6. OpenNews: Доступен пакетный менеджер DNF 2.0, пришедший на смену Yum
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/54483-dnf
Ключевые слова: dnf, yum
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (59) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Чебур (?), 11:41, 29/01/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    > По сравнению с Yum, DNF обладает заметно более высокой скоростью работы

    Стесняюсь спросить, а Yum получается вообще не работал? Просто мне трудно представить что-то более тормозное чем DNF.

     
     
  • 2.2, Анонимленьлогиниться (?), 11:56, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Стесняюсь спросить, а Yum получается вообще не работал?

    Работал, но потреблял больше памяти и дольше ресольвил (впрочем, заметно разве что на сверхдешевых VPS или при глобальном обновлении версии дистрибутива).

    > Просто мне трудно представить что-то более тормозное чем DNF

    Эм. А что именно тормозное? Резольвинг через libsolv - так он нынче почти во всех rpm-based используется. Применение deltarpm? Сама установка пакетов? Так это внутри librpm делается, там много всяких действий (контрольные суммы и тп..).

    Задача "установить пакет или пачку обновлений" обычно выполняется за 3-4 секунды в dnf...

     
     
  • 3.3, rinat85 (ok), 12:02, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Он действительно больше думает и тяжелее, чем pacman и apt, но видя разницу в "интеллекте" и функционале, достаточно простительно. Ну ещё может быть человек не настроил толком dnf, сам не пойму, почему майнтейнеры не поменяют параметры по умолчанию на что-то более адекватное, хотя это совершенно безопасно
     
     
  • 4.6, Анонимище (?), 12:46, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А как правильно настроить dnf?
     
     
  • 5.9, Анонимленьлогиниться (?), 13:17, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А как правильно настроить dnf?

    Отключить delta rpm если канал широкий?..

     
  • 5.31, Аноним (-), 19:01, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А как правильно настроить dnf?

    Путем замены на apt :P

     
     
  • 6.48, Аноним (48), 08:29, 30/01/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Спасибо, ненужно)
     
  • 5.32, IRASoldier_registered (ok), 19:11, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    DNF Configuration Reference

    https://dnf.readthedocs.io/en/latest/conf_ref.html

    Кури. Всё написано и разжёвано.

     
     
  • 6.40, Анонимище (?), 20:44, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А где раздел "Правильная настройка dnf"?
     
     
  • 7.42, IRASoldier_registered (ok), 00:25, 30/01/2021 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Мозги себе настрой правильно сначала.


     
  • 4.20, лютый жабби__ (?), 15:27, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • –4 +/
    >Он действительно больше думает и тяжелее, чем pacman и apt, но видя разницу в "интеллекте" и функционале, достаточно простительно

    Зачем сравнивать няшу пакмана и apt, который небось тоже на пистоне накалякан... по крайней мере работает с такой скоростью

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

     
     
  • 5.24, Аноним (24), 17:26, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хватит людей троллить, толсто слишком, они не поймут.
     
  • 2.5, Анонимище (?), 12:33, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Так то он быстрый, но по любому чиху скачивает какие-то метаданные, что, собственно, и производит впечатление, что dnf "тормознутый".
     
     
  • 3.8, Анонимленьлогиниться (?), 13:16, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Так то он быстрый, но по любому чиху скачивает какие-то метаданные, что,
    > собственно, и производит впечатление, что dnf "тормознутый".

    Ааа! Так вот вы про что. Но так это имеет смысл если делать update. Чем это хуже, чем двухэатпный apt-get update / upgrade?

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

    Правда, само подтягиватся только базовая информация о пакетах для операций update / install по имени пакета или provides зависимости. Полные метаданные для установки по имени внутри пакета (типа dnf install /usr/bin/some-cool-binary) тяжеловаты и нужны не так часто, их придется тянуть..

     
     
  • 4.41, kissmyass (?), 21:42, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    yum-cron

    а вот нахрена было yum переименовывать в dnf не понимаю, ну выпустили бы мажорную версию и всё

     
     
  • 5.52, Анонимленьлогиниться (?), 17:52, 31/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > а вот нахрена было yum переименовывать в dnf не понимаю, ну выпустили бы мажорную версию и всё

    https://developers.redhat.com/blog/2016/08/30/why-red-hats-new-dnf-package-man

     
  • 3.30, Аноним (-), 19:01, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так то и питон не тормозит, если ничего не делает... а это быстрое минимум 512 мегов на виртуалке требует, иначе кадавр лопается. С брызгами, убивая свои базы наповал.
     
  • 2.7, n00by (ok), 12:48, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > мне трудно представить
    > что-то более тормозное чем DNF.

    Представьте, что каждое чтение БД установленных пакетов с правами root вызывает перестройку индексов и сохранение их с последующим fdatasync. Вся система при этом встаёт колом на некоторое время. 1ГБ обновлений устанавливается 3 (три) часа (на SSD). Разработчики про это не знают, поскольку у них в виртуалочке проблема не проявляется. А когда узнают, ничего не могут поделать, кроме как сгрузить решение проблемы на пользователей. Это называется RPM5 в Rosa Tresh.

     
     
  • 3.14, yamah (?), 13:42, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Что за бред про RPM5 и три часа на SSD?
    4,8 ГБ на HDD SATA2 менее 20 минут ставится на Core2Duo E7300.
    Ну а чтобы система висела колом, ее надо было ставить на первые Atom и 512 МБ ОЗУ с диском на USB.
     
     
  • 4.19, n00by (ok), 15:09, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Что за бред про RPM5 и три часа на SSD?

    Я не специалист по таким диагнозам. Знаю лишь, что для активистов Rosa характерно отрицать объективную реальность, не имея о ней представления.

    > 4,8 ГБ на HDD SATA2 менее 20 минут ставится на Core2Duo E7300.

    А ты удали вот этот патчик https://abf.io/import/rpm/commit/4fb14f47db87dd2bbc693befc540b8e812f0c26b
    который Алзим подобрал с форума https://forum.rosalinux.ru/viewtopic.php?p=88972#p88972
    и наслаждайся. Только лучше SSD подключи, пусть Rosa Tresh его убивает, как вы делали с железом других.

    Тем более, персонально ты лишён права на использование, за хамство.

    > Ну а чтобы система висела колом, ее надо было ставить на первые
    > Atom и 512 МБ ОЗУ с диском на USB.

    Хватит обманывать пользователей.

    15 мар 2015, *)
    "Во время работы rpm из под root, в iotop показывается в графе IO 99.99% у нескольких kworker, у kjournald и столько же у самого процесса rpm. Почему так может быть? Аналогично на urpmi. Когда идет проверка обновления, работать невозможно."
    https://forum.rosalinux.ru/viewtopic.php?f=53&t=5355&p=40304

    *) исправлено 29 мая 2018

     
  • 2.10, Аноним (10), 13:19, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >> По сравнению с Yum, DNF обладает заметно более высокой скоростью работы
    > Стесняюсь спросить, а Yum получается вообще не работал? Просто мне трудно представить
    > что-то более тормозное чем DNF.

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

     
     
  • 3.11, Аноним (10), 13:20, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >> Стесняюсь спросить, а Yum получается вообще не работал? Просто мне трудно представить
    >> что-то более тормозное чем DNF.
    > Работал, более того ещё чуть меньше года назад, когда я ставил федорку
    > натыкался на то, что ни их замечательный гуёвый пакетник не находил
    > нужного мне пакета, при том что он был в подключённом репозитории,
    > ни DNF, а вот работающие ещё в то время команды Yum
    > - находили, почему так - без понятия, я не стал разбираться,
    > потому что федорка не мой основной дистр, просто пришлось его поюзать.
    > Никого ни в чём не обвиняю, ничего не ожидаю, просто занятный
    > факт был для меня.

    Да, и DNF субъективно выглядел увереннее, я надеюсь его допилят, однако, как говориться "fuck'Т налицо"

     
  • 3.12, dalco (ok), 13:29, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    По моему личному опыту прикол вот в чём:

    dnf list hren* - может найти "хрень" со товарищи в репозитории, а может и не найти. хз почему. У yum'а реально с этим проблем не было.

    dnf list "hren*" - работает 100%.

    Так что, обычно по привычке использую первый вариант (без кавычек). А если не срабатывает, использую второй. :)

     
     
  • 4.13, ryoken (ok), 13:34, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Логичнее было бы переприучаться ко второму, чтоб время не тратить :).
     
     
  • 5.16, DildoZilla (?), 14:40, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Передрессировываться. Все эти вкручивания то dnf, то wayland, то systemd, то npf напоминают навязывание ношения масок: "ой-ой, без этого ваще капец, ваши линуксы съедят ужасни ксакепы!!!"
     
     
  • 6.17, ryoken (ok), 14:44, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Так федора оно полигон, так чтА..:)
     
  • 4.15, Stax (ok), 13:48, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > dnf list hren* - может найти "хрень" со товарищи в репозитории, а может и не найти. хз почему

    Тссс! Я вам по секрету расскажу, почему.

    Потому что * раскрывает bash, а не dnf (у нас все ж таки не ms dos тут, ага). И если у вас в текущем каталоге есть файлик hrenovina.txt, то команда (невидимо для вас) башем превращается в dnf list hrenovina.txt - и он не найдет.

    А при экранировании * видит сам dnf.

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

     
     
  • 5.18, ryoken (ok), 14:45, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Потому что * раскрывает bash, а не dnf (у нас все ж

    А кто вам сказал, что у товарища выше - bash?

     
     
  • 6.50, Анонимленьлогиниться (?), 10:34, 30/01/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Потому что * раскрывает bash, а не dnf (у нас все ж
    > А кто вам сказал, что у товарища выше - bash?

    Да пусть хоть csh у него. Любой юникосвый шелл так делает. Это часть POSIX.

     
  • 5.23, dalco (ok), 16:40, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    О, спасибо! Ваше объяснение очень похоже на правду.
    Но, честное слово, почему-то за yum'ом я такого поведения не помню. Быть может, потому, что yum'ом пользовался уже достаточно давно.
     
  • 4.55, Аноним (55), 20:19, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > По моему личному опыту прикол вот в чём:
    > dnf list hren* - может найти "хрень" со товарищи в репозитории, а
    > может и не найти. хз почему. У yum'а реально с этим
    > проблем не было.
    > dnf list "hren*" - работает 100%.
    > Так что, обычно по привычке использую первый вариант (без кавычек). А если
    > не срабатывает, использую второй. :)

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

     
  • 4.57, анонъчик (?), 13:24, 04/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Так это ж шеллопроблемы. У меня точно также на zsh не хочет работать без кавычек.
     
  • 2.21, Аноним (21), 15:39, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Просто мне трудно представить что-то более тормозное чем DNF

    zypper

     
     
  • 3.56, Аноним (55), 20:20, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >> Просто мне трудно представить что-то более тормозное чем DNF
    > zypper

    А вот не надо, zypper кстати довольно неплох, в отличии от самой среды где он используется))

     

  • 1.4, Аноньимъ (ok), 12:13, 29/01/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >DNF является ответвлением от Yum 3.4, адаптированным для работы с Python 3

    Из описания получается что это менеджер питоновских пакетов.

     
  • 1.22, Аноним (22), 16:15, 29/01/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Базовый обязательный софт операционки на питоне - ну такое.
     
     
  • 2.27, Аноним (27), 18:39, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На смеси перла с башем всяко лучше, конечно (см. дебиан)
     
     
  • 3.29, Аноним (-), 18:59, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    На C++ не хотел? А таки dpkg и apt именно на этом. Перловка там очень сильно сбоку, в всякой вспомогаловке типа debconf. И то есть cdebconf.
     
     
  • 4.51, Анонимленьлогиниться (?), 17:46, 31/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Так и в dnf все по факту на C. Ресольвит через libsolv, качает через librepo, ставит через librpm. А на питоне только клей для связки этих компонент (впрочем, есть у кого-то желание и от клея уйти в пользу чисто сишного libdnf, делающего все это).
     
  • 2.53, eganru (?), 10:00, 01/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В gentoo portage на питоне.

    Работает - и слава богу.

     

  • 1.25, Ssss (?), 18:01, 29/01/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Что только не делают, лишь бы не юзать дебиан или убунту с божественным apt
     
     
  • 2.46, srgazh (ok), 03:09, 30/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    apt update && apt upgrade && apt install zolupa VS dnf install zolupa ??
     
     
  • 3.59, анонъчик (?), 13:45, 04/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Немного некорректное сравнение. apt update && apt upgrade && apt install zolupa vs dnf upgrade --refresh -y && dnf install zolupa.
     

  • 1.26, mos87 (ok), 18:32, 29/01/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Did Not Finish

    //шапка о5

     
  • 1.28, Аноним (-), 18:57, 29/01/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Спасибо yum и dnf. Если бы не это УГ, я бы никогда не поставил убунту и дебиан, и не узнал бы что оказывается можно и намного лучше пакетные менеджеры писать.
     
     
  • 2.36, Аноним (36), 19:43, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Рассказывайте дальше про днище под названием apt deb, которые лёгким движением р... большой текст свёрнут, показать
     
     
  • 3.38, Аноним (36), 19:51, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Блин, пропустил три запятые - прошу прощения.
     
  • 3.43, Аноним (-), 00:45, 30/01/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У меня проблемы с чем-то таким были 1 раз за 15 лет, к тому же он сам подсказал ... большой текст свёрнут, показать
     
     
  • 4.45, Аноним (36), 02:46, 30/01/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    512MB OOM?

    Болезненный, вы пытались без свопа F33 гонять с таким объемом RAM на VPS? Сочувствую. Системные требования F33 сказать или сами найдёте?

    За 25 лет использования RPM с обёртками не видел OOM ни разу.

    Темы по поводу поломанного apt'a тем временем появляются постоянно и часто, а на dnd/rpm что-то не жалуются.

    Брехню и извращения оставьте при себе.

    А тема с ядрами: это то, что убунта до недавнего времени автоматом ставила ядра без удаления старых версий, пока не забивала /boot и не ломала обновления.

    Сказочники, короче. Вылез.

    Тьфу ты.

    // b.

     
     
  • 5.47, Аноним (-), 04:21, 30/01/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да спасибо, у меня дебианы, вон даже 128 без свопа есть, изолирует 1 конкретный ... большой текст свёрнут, показать
     
  • 3.58, анонъчик (?), 13:38, 04/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > dnf remove - тупо удаляет всё, кроме изменённых конфигурационных файлов.

    Не всегда. Несколько раз замечал, что dnf remove иногда может удалить не все пакеты, вдобавок dnf autoremove потом их не подчищает, делать же dnf history undo <номер_транзакции> тоже не всегда вариант, особенно если транзакция древняя и с тех пор зависимые пакеты по сто раз обновились.

     

  • 1.33, Аноним (36), 19:25, 29/01/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Столько г0вна вылито на DNF - вы им когда последний раз пользовались У меня Cor... большой текст свёрнут, показать
     
     
  • 2.35, Аноним (35), 19:40, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Столько г0вна вылито на DNF - вы им когда последний раз пользовались?

    1. И по делу. Ведь можно такое и на bash зафигачить, бгг.
    2. НЕ пользовались и НЕ собираемся ;)

     
     
  • 3.37, Аноним (36), 19:44, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Не пользовался (или пользовался лет 10 назад), не видел, но осуждаю™.

    Суть большинства ответов в теме.

    // b.

     
     
  • 4.39, Аноним (35), 19:52, 29/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Суть большинства ответов в теме.

    Это интуитивно понятно, друхх, как например то, что наступать на крышку люка не стоит)) + камент ниже.

     
  • 2.49, Аноним (48), 08:35, 30/01/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Просто критики не в курсе за dnf makecache (чит. их любимое apt-get update), пишут с лету dnf install someshit и залипают на обновление реп)))
     

  • 1.34, Аноним (35), 19:37, 29/01/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Петон? -> Попса, "промышленный быдлокод"? Не видели вы zypper'а))
     
     
  • 2.44, Аноним (-), 00:46, 30/01/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Петон? -> Попса, "промышленный быдлокод"? Не видели вы zypper'а))

    А зачем на них смотреть когда есть дебиан и apt :)

     
     
  • 3.54, adolfus (ok), 19:21, 01/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    И чем же так хороша структура дебиановских репозиториев? Помимо, собственно, пакетов там гора каких-то левых каталогов и файлов, назначение которых совершенно непонятно. По дюжине версий одного и того же приложения, например, миднайт-коммандер представлен всеми версиями c 2014 по 2021 годы. Это не репозиторий, а помойка.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру