Анонсирован (http://dnf.baseurl.org/2015/05/11/dnf-1-0-and-dnf-plugins-co.../) релиз пакетного менеджера DNF 1.0 (http://dnf.readthedocs.org/en/latest/release_notes.html#id43), ознаменовавший стабилизацию кодовой базы и готовность для использования в качестве основного пакетного менеджера в дистрибутиве Fedora 22. Новый выпуск также примечателен поддержкой работы с репозиториями, использующими HTTP basic-аутентификацию.
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.
C точки зрения опций командной строки и файлов конфигурации, DNF почти полностью совместим с YUM. Из наиболее заметных отличий (http://dnf.readthedocs.org/en/latest/cli_vs_yum.html) можно отметить: идентичность команд update и upgrade, прекращение поддержки опции "--skip-broken", прекращение поддержки команд "resolvedep" и "deplist" вместо которых следует использовать "dnf provides" и "dnf repoquery --requires", возможностью фильтрации по маске для всех команд, прекращение поддержки некоторых опций конфигурации и изменение настроек по умолчанию. Несмотря на то, что Yum ещё будет поддерживаться некоторое время, данный проект официально объявлен (http://dnf.baseurl.org/2015/05/11/yum-is-dead-long-live-dnf/) завершившим свой жизненный цикл. Для автоматизации перехода с Yum на DNF и конвертации имеющихся метаданных подготовлен специальный плагин migrate (http://dnf-plugins-extras.readthedocs.org/en/latest/migrate....).
URL: http://dnf.baseurl.org/2015/05/11/dnf-1-0-and-dnf-plugins-co.../
Новость: http://www.opennet.me/opennews/art.shtml?num=42209
> Увидел свет пакетный менеджер DNFу меня дежавю? :-) ...или это уже какой по счёту раз?
> у меня дежавю? :-) ...или это уже какой по счёту раз?Эх, ты! Радоваться надо, смотри сюда:
"Новый выпуск также примечателен поддержкой работы с репозиториями, использующими HTTP basic-аутентификацию."
Ты хоть представляешь, что сие означает - это же прорыв, прорыв в неизведанное! Самое последнее слово в обеспечении безопасности!
> "Новый выпуск также примечателен поддержкой работы с репозиториями, использующими HTTP basic-аутентификацию."Новый выпуск также примечателен поддержкой работы с репозиториями
FIXED
> Самое последнее слово в обеспечении безопасности!Согласен, последние времена настают...
Слушайте, а почему не напишут на C/C++ или на GO? Давно ведь проситься, а то ведь питон же уходит в лету с каждой секундой.
может ещё и на C# написать попросишь? :-)Python самое то -- для задач административных утилит!
потому как чуть менее примитивный чем кривой Bash, и на много проще чем компилируемые языки
zypper на плюсах написан, и ничего, работает, питона в зависимостях не просит...
> zypper на плюсах написан, и ничего, работает, питона в зависимостях не просит...Так это же ретроградная поделка, то ли дело Петон - современно, надёжно, молодёжно.
Питону уже сто лет в обед. А модно и молодёжно - это гоу, раст и им подобные.
Бздшный pkg вообще на Сях - портируйте и будет вам Щастье :)
Зачем, если есть aptitude?
Я бы не стал доверять питону обновление системы.Это не рядовая административная задача.
Но в данном случае на нем много раз наступали на грабли.
Можно было бы его заменить.
Но видимо ума хватает только на питон.
Portage тоже на python, но не видно чтобы гентушники жаловались.
> Portage тоже на python, но не видно чтобы гентушники жаловались.А чего им жаловаться то? когда апдейт мира длиться в среднем 30 минут.
Тут хоть на си напиши лучше не станет.
Я помню апдейт мира на Pentium I занимал у меня трое суток и после этого я сразу перешел на Debian, но потом всетаки немного образумился и вернулся на CentOS.
На дебиан наговаривать? Это ты зря...
Честно говоря, наличие среди утилит работающих на питоне и перле осложняют жизнь гентушникам. Жалуемся.
Как решение разве что http://paludis.exherbo.org/index.html могу предложить.
питон не обновляет систему, если шо.
Он говорит, какие пакеты нужно установить. Обновляет rpm ;)
Тсс, никому не говори, а то у школьников бомбить начнет
Иди почитай еще раз как наставляться rpm'ки. Подсказка есть такая штука librpm.
> Python самое то -- для задач административных утилит!Ждем от тебя замену systemd на питоне.
>> Python самое то -- для задач административных утилит!
> Ждем от тебя замену systemd на питоне.предлагаю назвать этот проект "SystemP" или "SystemPD" ;)
> Python самое то -- для задач административных утилит!Есть старое детское проклятье -- "чтоб ты в туалет по компасу ходил"; почему-то вспомнилось...
Питон - самое то для реализации логики (для этой цели язык вполне ничего, плюс, согласен, нету гемора с компиляциями и пр), а команды вызывать на Баше всё же поудобней будет
> Питон - самое то для реализации логики (для этой цели язык вполне
> ничего, плюс, согласен, нету гемора с компиляциями и пр), а команды
> вызывать на Баше всё же поудобней будетлогика подсказывает что для реализации "логики" лучше ....Логические ЯП, то есть Пролог, Руби, Эрланг, соотф. идеально с элементами ФП, как в APL, D, Erlang и прочими ништяками жизненными :)
А лучше всего для системных элементов - что-нибудь с вменяемым синтаксисом, чтобы при необходимости влезть в исходники не разбираться, а где же там пробельчик лишний, или почему операнды в обратном порядке, или что делает вот энта вот херамбула из 10 спецсимволов подряд, которая ещё и не регэкс. Т.е. всё перечисленное выше (вместе с пистоном и перлом) практически отпадает. Шарпы с жабой отпадают из-за монструозности (а где там вот этот 100500-й класс в 999 модуле 666 уровня вложенности?). Остаются C, плюсы, баш (дань традиции), ну и скриптовые языки с C-подобным синтаксисом (из таковых только PHP на ум приходит, и с монструозностью рантайма у него, конечно, тоже не всё гладко, но по крайней мере баланс native code/script там соблюдается лучше).Да, в сях и прочих тоже есть свои сложности - но там хотя бы синтаксис человеческий. Лучше потратить время на собственно однократное изучение сложной логики, чем на регулярный разбор выдуманной для повышения ЧСВ тарабарской грамоты.
теоретик?
вот честно, написали сами что-нибудь в своей жизни сложнее "хэллоу ворда", особенно на перечисленных языках, или так, по набору фич посмотрели, что "лучше подходит" для данной задачи?
> теоретик?
> вот честно, написали сами что-нибудь в своей жизни сложнее "хэллоу ворда", особенно
> на перечисленных языках, или так, по набору фич посмотрели, что "лучше
> подходит" для данной задачи?Я вполне себе пишу на нескольких из вышеперечисленных языков, и начинал вообще с ассемблера. Так что претензия мимо кассы.
Или это не мне было? xD
> Слушайте, а почему не напишут на C/C++ или на GO? Давно ведь
> проситься, а то ведь питон же уходит в лету с каждой секундой.Если писать со встроенными драйверами распределённых рассчётов, происходящих на какойнить куде, да ещё квейк туда вставить в качестве нескучного интерфейса выбора устанавливаемых пакетов, сглаживающего время ожидания подсчёта зависимостей, и систему обмена данными с хабблом и загрузку на systemd, тогда -- да, нужен C/C++.
>> Слушайте, а почему не напишут на C/C++ или на GO? Давно ведь
>> проситься, а то ведь питон же уходит в лету с каждой секундой.
> Если писать со встроенными драйверами распределённых рассчётов, происходящих на какойнить
> куде, да ещё квейк туда вставить в качестве нескучного интерфейса выбора
> устанавливаемых пакетов, сглаживающего время ожидания подсчёта зависимостей, и систему
> обмена данными с хабблом и загрузку на systemd, тогда -- да,
> нужен C/C++.Для того что бы послать питоно-фанбоя нужны всего 8 букв. *** ** ***
>> созданной в рамках проекта openSUSEЛучше бы обе системы использовали zypper, но нет, каждый пишет свой велосипед!
А ответ находится очень близко: https://fedoraproject.org/wiki/Features/DNF#Why_not_zif.2Fzy...
Детские отмазки для прикрытия NIH синдрома.
> Детские отмазки для прикрытия NIH синдрома.Не совсем так. С одной стороны, шляпа хочет контролировать _всё_, что поставляет (upstart они уже покушали). С другой -- "в качестве основных проблем Yum, которые побудили к созданию DNF" не упоминают главную: трагическую смерть разработчика yum, повлёкшую невозможность его поддержки имеющимися силами. Тот самый bus factor в единицу.
я не так давно с удивлением заметил, что rpm линкуется с lua... я не знаю, можно ли было развивать yum дальше, но все это выглядит что-то без единого дизайна и со всех сторон подкостыленное разными lua, python ... и до кучи каким-то "хакки" (hawkey - наконец все хаки объединили в библиотеку).
> я не так давно с удивлением заметил, что rpm линкуется с lua...
> я не знаю, можно ли было развивать yum дальше, но все
> это выглядит что-то без единого дизайна и со всех сторон подкостыленное
> разными lua, python ... и до кучи каким-то "хакки" (hawkey -
> наконец все хаки объединили в библиотеку).Так! Плюсанул.
>> прекращение поддержки опции "--skip-broken"это они "хорошо" придумали:)
А в замен то что?
Эта опция теперь там по умолчанию включена.
Это они еще лучше придумали.
> Это они еще лучше придумали.Фороникс тоже http://www.phoronix.com/scan.php?page=news_item&px=DNF-One-P... фшоке.
>API для плагинов и интеграции с другими приложениями, такими как инсталлятор AnacondaОно еще живо?
Кривейшее поделее, выжирающее память гигабайтами, с системными требованиями большими чем у самого дистрибутива.
>> такими как инсталлятор Anaconda
> Оно еще живо? Кривейшее поделие, выжирающее память гигабайтамиНасколько помню, жручим шляпный инсталер стал после того, как его пересадили на урезанную гномосессию -- пока стартовали иксы и поверх них змеюка, так вроде ещё как-то держались...
А зачем в fedor'е нужен dnf? Ведь теперь он, как и PackageKit - настройка над hawkey. Кому нужна консоль - есть pkcon.
yum install nano
Разве не локанично? Разве это не идеальная команда, которая самостоятельно, без показа рекламы и установки амиго-браузера поможет вам в быту?
питон не модно, лучше бы новый язык придумали
> питон не модно, лучше бы новый язык придумалиТак это, того... http://ceylon-lang.org/
А почему не http://www.rust-lang.org/ ??
Как много оказывается ЯП с доменом *-lang.org (https://goo.gl/eVT3Jp)
Есть еще без тире, например http://hacklang.org/
дистры с пакетным менеджером, елозящим на Perl, Ruby и даже PHP, Tcl, JS - были уже.
даже с Lua было :)
так что бидон - не так фигово.
вот залудят для него JIT, жабо-стайл(а не как в фэйсбукес сделано, масштабируемо, но меееедленно) - будет прикольнее, хотя в целом, конечно - не труЪ подход и язык.
> труЪ подход и язык.Да, вот только JIT'а для компонентов системы нам и не хватает для полного счастья. Чтобы как у MS - при каждом апдейте системного класса 100500 уровня зависимости 99% ресурсов проца на JIT на десять минут, а юзер подождёт.
да и с питоном были.мне месяц назад тут рассказывали, что emerge (python, gentoo) гораздо тормознее homebrew (ruby, mac) из-за неисчерпаемой функциональности.
впрочем, yum и emerge -- птицы где-то одинаковой неторопливости. можно быстрее.
На днях попользовался сим чудом в 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 без его очистки. Всякие их новые опции не помогли.
Это всего только первая версия и ее конечно же расширят. Но на данный момент отличия все таки, как по мне, значительные. Отличия или баги?
Удачи разработчикам.
В таких постах очень неплохо в конце смотрятся ссылки на баг-репорты.
Вот, например, практически мой случай:
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=1203491Bug 1203491 имеет статус NEW и не закрыт.
Если так любите читать баги по DNF, тогда Вам сюда:
https://bugzilla.redhat.com/buglist.cgi?component=dnf&produc...Взгляд на один только этот список говорит, что проблем очень много.
Желаю удачи разработчикам. Надеюсь, что DNF может и будет в будущем хорошей заменой Yum. Хотя последний меня устраивает.
В релизе Fedora 22 'dnf download --resolve ...' вроде как починили. Пользуюсь три дня с момента установки и пока все в порядке с зависимостями. Для закачки пакетов только под конкретную архитектуру можно добавлять расширение (например: .х86_64) и/или маску (например: *). Например: dnf download --resolve mc.x86_64