The OpenNET Project / Index page

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

Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yum

11.05.2015 23:46

Анонсирован релиз пакетного менеджера DNF 1.0, ознаменовавший стабилизацию кодовой базы и готовность для использования в качестве основного пакетного менеджера в дистрибутиве Fedora 22. Новый выпуск также примечателен поддержкой работы с репозиториями, использующими HTTP basic-аутентификацию.

DNF является ответвлением от Yum 3.4, созданным для развития некоторых новых идей, таких как использование библиотеки hawkey в качестве бэкенда для разрешения зависимостей. В качестве основных проблем Yum, которые побудили к созданию DNF, называют некачественную документацию на API, проблемный алгоритм разрешения зависимостей и невозможность рефакторинга внутренних функций. По сравнению с Yum, DNF обладает заметно более высокой скоростью работы, низким потреблением памяти и более качественным управлением зависимостями. Кроме того, DNF может выполняться как при помощи Python 2, так и Python 3, что позволяет реализовать план по поставке Python 3 в Fedora по умолчанию.

Для разрешения зависимостей в DNF задействован SAT solver, реализованный в библиотеке libsolv (hawkey выступает в роли надстройки над libsolv), созданной в рамках проекта openSUSE. Обработки метаданных и загрузка пакетов выполняется через librepo. Для расширения функциональности DNF предоставляет новый, не совместимый с Yum, API для плагинов и интеграции с другими приложениями, такими как инсталлятор Anaconda.

C точки зрения опций командной строки и файлов конфигурации, DNF почти полностью совместим с YUM. Из наиболее заметных отличий можно отметить: идентичность команд update и upgrade, прекращение поддержки опции "--skip-broken", прекращение поддержки команд "resolvedep" и "deplist" вместо которых следует использовать "dnf provides" и "dnf repoquery --requires", возможностью фильтрации по маске для всех команд, прекращение поддержки некоторых опций конфигурации и изменение настроек по умолчанию. Несмотря на то, что Yum ещё будет поддерживаться некоторое время, данный проект официально объявлен завершившим свой жизненный цикл. Для автоматизации перехода с Yum на DNF и конвертации имеющихся метаданных подготовлен специальный плагин migrate.

  1. Главная ссылка к новости (http://dnf.baseurl.org/2015/05...)
  2. OpenNews: Бета-выпуск Fedora 22, перешедший на пакетный менеджер DNF
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/42209-dnf
Ключевые слова: dnf, yum, rpm
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (57) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 00:44, 12/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +14 +/
    > Увидел свет пакетный менеджер DNF

    у меня дежавю? :-) ...или это уже какой по счёту раз?

     
     
  • 2.6, Анончег (?), 02:00, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +10 +/
    > у меня дежавю? :-) ...или это уже какой по счёту раз?

    Эх, ты! Радоваться надо, смотри сюда:

    "Новый выпуск также примечателен поддержкой работы с репозиториями, использующими [b]HTTP basic-аутентификацию.[/b]"

    Ты хоть представляешь, что сие означает - это же прорыв, прорыв в неизведанное! Самое последнее слово в обеспечении безопасности!

     
     
  • 3.17, Аноним (-), 09:01, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > "Новый выпуск также примечателен поддержкой работы с репозиториями, использующими [b]HTTP basic-аутентификацию.[/b]"

    Новый выпуск также примечателен поддержкой работы с репозиториями
    FIXED

     
  • 3.47, Sergey722 (ok), 09:00, 13/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Самое последнее слово в обеспечении безопасности!

    Согласен, последние времена настают...

     

  • 1.2, Аноним (-), 00:52, 12/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    Слушайте, а почему не напишут на C/C++ или на GO? Давно ведь проситься, а то ведь питон же уходит в лету с каждой секундой.
     
     
  • 2.3, Xasd (ok), 00:58, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    может ещё и на C# написать попросишь? :-)

    Python самое то -- для задач административных утилит!

    потому как чуть менее примитивный чем кривой Bash, и на много проще чем компилируемые языки

     
     
  • 3.5, Аноним (-), 01:41, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +10 +/
    zypper на плюсах написан, и ничего, работает, питона в зависимостях не просит...
     
     
  • 4.7, Анончег (?), 02:03, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > zypper на плюсах написан, и ничего, работает, питона в зависимостях не просит...

    Так это же ретроградная поделка, то ли дело Петон - современно, надёжно, молодёжно.

     
     
  • 5.15, anonymous (??), 07:39, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Питону уже сто лет в обед. А модно и молодёжно - это гоу, раст и им подобные.
     
  • 4.29, Аноним (-), 17:29, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Бздшный pkg вообще на Сях - портируйте и будет вам Щастье :)
     
     
  • 5.48, Sergey722 (ok), 09:02, 13/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем, если есть aptitude?
     
  • 3.9, Аноним (-), 04:04, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Я бы не стал доверять питону обновление системы.

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

     
     
  • 4.10, AsukaLangleyfag (?), 04:37, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Portage тоже на python, но не видно чтобы гентушники жаловались.
     
     
  • 5.13, Аноним (-), 06:13, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Portage тоже на python, но не видно чтобы гентушники жаловались.

    А чего им жаловаться то? когда апдейт мира длиться в среднем 30 минут.
    Тут хоть на си напиши лучше не станет.

     
     
  • 6.53, Аноним (-), 01:54, 14/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Я помню апдейт мира на Pentium I занимал у меня трое суток и после этого я сразу перешел  на Debian, но потом всетаки немного образумился и вернулся на CentOS.
     
     
  • 7.57, anonimous (?), 15:20, 15/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    На дебиан наговаривать? Это ты зря...
     
  • 5.28, redwolf (ok), 15:22, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Честно говоря, наличие среди утилит работающих на питоне и перле осложняют жизнь гентушникам. Жалуемся.
     
     
  • 6.39, AsukaLangleyfag (?), 23:16, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Как решение разве что http://paludis.exherbo.org/index.html могу предложить.
     
  • 4.21, Владимир (??), 09:14, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    питон не обновляет систему, если шо.
    Он говорит, какие пакеты нужно установить.  Обновляет rpm ;)
     
     
  • 5.32, Пингвино (ok), 18:50, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тсс, никому не говори, а то у школьников бомбить начнет
     
     
  • 6.44, Аноним (-), 05:18, 13/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Иди почитай еще раз как наставляться rpm'ки. Подсказка есть такая штука librpm.
     
  • 3.14, Аноним (-), 07:01, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Python самое то -- для задач административных утилит!

    Ждем от тебя замену systemd на питоне.

     
     
  • 4.37, Аноним (-), 22:52, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> Python самое то -- для задач административных утилит!
    > Ждем от тебя замену systemd на питоне.

    предлагаю назвать этот проект "SystemP" или "SystemPD" ;)

     
  • 3.18, Michael Shigorin (ok), 09:05, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Python самое то -- для задач административных утилит!

    Есть старое детское проклятье -- "чтоб ты в туалет по компасу ходил"; почему-то вспомнилось...

     
  • 3.23, anonymous (??), 10:58, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Питон - самое то для реализации логики (для этой цели язык вполне ничего, плюс, согласен, нету гемора с компиляциями и пр), а команды вызывать на Баше всё же поудобней будет
     
     
  • 4.36, Аноним (-), 22:51, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Питон - самое то для реализации логики (для этой цели язык вполне
    > ничего, плюс, согласен, нету гемора с компиляциями и пр), а команды
    > вызывать на Баше всё же поудобней будет

    логика подсказывает что для реализации "логики" лучше ....Логические ЯП, то есть Пролог, Руби, Эрланг, соотф. идеально с элементами ФП, как в APL, D, Erlang и прочими ништяками жизненными :)

     
     
  • 5.40, AlexAT (ok), 23:36, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А лучше всего для системных элементов - что-нибудь с вменяемым синтаксисом, чтобы при необходимости влезть в исходники не разбираться, а где же там пробельчик лишний, или почему операнды в обратном порядке, или что делает вот энта вот херамбула из 10 спецсимволов подряд, которая ещё и не регэкс. Т.е. всё перечисленное выше (вместе с пистоном и перлом) практически отпадает. Шарпы с жабой отпадают из-за монструозности (а где там вот этот 100500-й класс в 999 модуле 666 уровня вложенности?). Остаются C, плюсы, баш (дань традиции), ну и скриптовые языки с C-подобным синтаксисом (из таковых только PHP на ум приходит, и с монструозностью рантайма у него, конечно, тоже не всё гладко, но по крайней мере баланс native code/script там соблюдается лучше).

    Да, в сях и прочих тоже есть свои сложности - но там хотя бы синтаксис человеческий. Лучше потратить время на собственно однократное изучение сложной логики, чем на регулярный разбор выдуманной для повышения ЧСВ тарабарской грамоты.

     
  • 5.49, anonymous (??), 12:27, 13/05/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    теоретик?
    вот честно, написали сами что-нибудь в своей жизни сложнее "хэллоу ворда", особенно на перечисленных языках, или так, по набору фич посмотрели, что "лучше подходит" для данной задачи?
     
     
  • 6.52, AlexAT (ok), 19:54, 13/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > теоретик?
    > вот честно, написали сами что-нибудь в своей жизни сложнее "хэллоу ворда", особенно
    > на перечисленных языках, или так, по набору фич посмотрели, что "лучше
    > подходит" для данной задачи?

    Я вполне себе пишу на нескольких из вышеперечисленных языков, и начинал вообще с ассемблера. Так что претензия мимо кассы.

    Или это не мне было? xD

     
  • 2.26, Аноним (-), 12:47, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Слушайте, а почему не напишут на C/C++ или на GO? Давно ведь
    > проситься, а то ведь питон же уходит в лету с каждой секундой.

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

     
     
  • 3.45, Аноним (-), 05:22, 13/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Слушайте, а почему не напишут на C/C++ или на GO? Давно ведь
    >> проситься, а то ведь питон же уходит в лету с каждой секундой.
    > Если писать со встроенными драйверами распределённых рассчётов, происходящих на какойнить
    > куде, да ещё квейк туда вставить в качестве нескучного интерфейса выбора
    > устанавливаемых пакетов, сглаживающего время ожидания подсчёта зависимостей, и систему
    > обмена данными с хабблом и загрузку на systemd, тогда -- да,
    > нужен C/C++.

    Для того что бы послать питоно-фанбоя нужны всего 8 букв. *** ** ***

     

  • 1.4, Аноним (-), 01:36, 12/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >> созданной в рамках проекта openSUSE

    Лучше бы обе системы использовали zypper, но нет, каждый пишет свой велосипед!

     
     
  • 2.11, AsukaLangleyfag (?), 05:37, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А ответ находится очень близко: https://fedoraproject.org/wiki/Features/DNF#Why_not_zif.2Fzypp.3F
     
     
  • 3.12, Аноним (-), 06:11, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Детские отмазки для прикрытия NIH синдрома.
     
     
  • 4.19, Michael Shigorin (ok), 09:08, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Детские отмазки для прикрытия NIH синдрома.

    Не совсем так.  С одной стороны, шляпа хочет контролировать _всё_, что поставляет (upstart они уже покушали).  С другой -- "в качестве основных проблем Yum, которые побудили к созданию DNF" не упоминают главную: трагическую смерть разработчика yum, повлёкшую невозможность его поддержки имеющимися силами.  Тот самый bus factor в единицу.

     
     
  • 5.38, crypt (ok), 22:57, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    я не так давно с удивлением заметил, что rpm линкуется с lua... я не знаю, можно ли было развивать yum дальше, но все это выглядит что-то без единого дизайна и со всех сторон подкостыленное разными lua, python ... и до кучи каким-то "хакки" (hawkey - наконец все хаки объединили в библиотеку).
     
     
  • 6.42, Анончег (?), 00:14, 13/05/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > я не так давно с удивлением заметил, что rpm линкуется с lua...
    > я не знаю, можно ли было развивать yum дальше, но все
    > это выглядит что-то без единого дизайна и со всех сторон подкостыленное
    > разными lua, python ... и до кучи каким-то "хакки" (hawkey -
    > наконец все хаки объединили в библиотеку).

    Так! Плюсанул.

     

  • 1.8, Аноним (-), 04:00, 12/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >> прекращение поддержки опции "--skip-broken"

    это они "хорошо" придумали:)

    А в замен то что?

     
     
  • 2.24, SunXE (ok), 11:04, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Эта опция теперь там по умолчанию включена.
     
     
  • 3.50, Аноним (-), 16:46, 13/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Это они еще лучше придумали.
     
     
  • 4.51, Andrey Mitrofanov (?), 16:52, 13/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Это они еще лучше придумали.

    Фороникс тоже http://www.phoronix.com/scan.php?page=news_item&px=DNF-One-Problem-So-Far фшоке.

     

  • 1.16, Аноним (-), 08:57, 12/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >API для плагинов и интеграции с другими приложениями, такими как инсталлятор Anaconda

    Оно еще живо?
    Кривейшее поделее, выжирающее память гигабайтами, с системными требованиями большими чем у самого дистрибутива.

     
     
  • 2.20, Michael Shigorin (ok), 09:09, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> такими как инсталлятор Anaconda
    > Оно еще живо? Кривейшее поделие, выжирающее память гигабайтами

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

     

  • 1.22, Аноним (-), 10:22, 12/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А зачем в fedor'е нужен dnf? Ведь теперь он, как и PackageKit - настройка над hawkey. Кому нужна консоль - есть pkcon.
     
     
  • 2.33, Илья (??), 20:21, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    yum install nano
    Разве не локанично? Разве это не идеальная команда, которая самостоятельно, без показа рекламы и установки амиго-браузера поможет вам в быту?
     

  • 1.25, Аноним (-), 12:15, 12/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    питон не модно, лучше бы новый язык придумали
     
     
  • 2.27, Аноним (-), 13:39, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > питон не модно, лучше бы новый язык придумали

    Так это, того... http://ceylon-lang.org/

     
     
  • 3.30, Stax (ok), 17:32, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А почему не http://www.rust-lang.org/ ??
     
     
  • 4.31, CrazyAlex25 (ok), 18:08, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Как много оказывается ЯП с доменом *-lang.org    (https://goo.gl/eVT3Jp)
     
     
  • 5.34, Аноним (-), 21:26, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Есть еще без тире, например http://hacklang.org/
     
  • 2.35, Аноним (-), 22:50, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    дистры с пакетным менеджером, елозящим на Perl, Ruby и даже PHP, Tcl, JS - были уже.
    даже с Lua было :)
    так что бидон - не так фигово.
    вот залудят для него JIT, жабо-стайл(а не как в фэйсбукес сделано, масштабируемо, но меееедленно) - будет прикольнее, хотя в целом, конечно - не труЪ подход и язык.
     
     
  • 3.41, AlexAT (ok), 23:45, 12/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > труЪ подход и язык.

    Да, вот только JIT'а для компонентов системы нам и не хватает для полного счастья. Чтобы как у MS - при каждом апдейте системного класса 100500 уровня зависимости 99% ресурсов проца на JIT на десять минут, а юзер подождёт.

     
  • 3.43, й (?), 01:11, 13/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да и с питоном были.

    мне месяц назад тут рассказывали, что emerge (python, gentoo) гораздо тормознее homebrew (ruby, mac) из-за неисчерпаемой функциональности.

    впрочем, yum и emerge -- птицы где-то одинаковой неторопливости. можно быстрее.

     

  • 1.46, Igor (??), 08:26, 13/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На днях попользовался сим чудом в Fedora 22 Beta 3.
    Пользуюсь Fedora где-то с 10-й версии. Если я тут чего-то не понял,
    то извините - пользовался DNF всего только 2 дня.
    Несколько слов по поводу совместимости - это практически другой менеджер, хотя и очень похожий.
    Стояла задача: выполнить локальное сохранение некоторого множества пакетов из репозитория с целью создания своего addon'a, как небольшого расширения стандартного iso-образа Workstation-сборки(без kikstart).
    Просто сохранить с целью дальнейшего хранения и установки по мере надобности своих групп пакетов с конкретным iso-образом (Увы, не всегда есть Inet под рукой).
    Так вот, в DNF есть команда download. Начну с нее. Например:
    dnf download gcc gcc-c++ kernel-devel
    Итог: закачка исключительно gcc, gcc-c++, kernel-devel!
    Yum с опцией --downloadonly сразу распознавал зависимости и качал только пакеты конкретной платформы, например, x86_64(если действительно i686 были не нужны).
    DNF качает эти пакеты БЕЗ ЗАВИСИМОСТЕЙ (!) и еще тащит дополнительно пакеты для платформы i686! Зачем? Поехали дальше.
    Казалось бы, есть хорошая опция --resolve и утверждается, что вместе с download можно получить как раз закачку с обработкой зависимостей!
    Но и тут лажа -- качает лишние пакеты!
    Специально проверял: dnf download --resolve ... и dnf install ... - во многих случаях выдает разные зависимости на закачку -- списки пакетов отличаются!
    Как? Почему? Почему нет однозначности списка закачиваемых пакетов?
    Ну и еще. В Yum была команда localinstall.
    В DNF, я так понял, ее совместили с install. Т.е.:
    Было: yum localinstall ./*.rpm
    Стало: dnf install ./*.rpm
    Кстати. В DNF я не нашел упоминание, как сделать закачку в cache без его очистки. Всякие их новые опции не помогли.
    Это всего только первая версия и ее конечно же расширят. Но на данный момент отличия все таки, как по мне, значительные. Отличия или баги?
    Удачи разработчикам.
     
     
  • 2.55, Аноним (-), 22:24, 14/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В таких постах очень неплохо в конце смотрятся ссылки на баг-репорты.
     
     
  • 3.56, Igor (??), 13:16, 15/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот, например, практически мой случай:
    Bug 1209638 - dnf is missing --downloadonly --downloaddir parameter
    https://bugzilla.redhat.com/show_bug.cgi?id=1209638
    Bug 1203491 - dnf cannot download a package group (like yum groupinstall --downloadonly)
    https://bugzilla.redhat.com/show_bug.cgi?id=1203491

    Bug 1203491 имеет статус NEW и не закрыт.

    Если так любите читать баги по DNF, тогда Вам сюда:
    https://bugzilla.redhat.com/buglist.cgi?component=dnf&product=Fedora

    Взгляд на один только этот список говорит, что проблем очень много.
    Желаю удачи разработчикам. Надеюсь, что DNF может и будет в будущем хорошей заменой Yum. Хотя последний меня устраивает.

     
  • 2.59, Igor (??), 08:50, 29/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    В релизе Fedora 22 'dnf download --resolve ...' вроде как починили. Пользуюсь три дня с момента установки и пока все в порядке с зависимостями. Для закачки пакетов только под конкретную архитектуру можно добавлять расширение (например: .х86_64) и/или маску (например: *). Например: dnf download --resolve mc.x86_64
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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