Ярослав Резник (http://fedoraproject.org/wiki/JaroslavReznik), входящий в состав управляющего совета Fedora Linux, опубликовал (https://lists.fedoraproject.org/pipermail/devel-announce/201...) в списке рассылки разработчиков официальное предложение по замене Yum на DNF (http://akozumpl.github.io/dnf/) в качестве пакетного менеджера по умолчанию, начиная с Fedora 22. Кроме того, среди пользователей инициировано (http://dnf.baseurl.org/2014/06/06/vote-for-yum-features-that.../) голосование о том, каких возможностей Yum не хватает в DNF, что поможет выбрать приоритетные направления разработки DNF.В предложении отмечается, что в настоящее время DNF достиг готовности полностью заменить Yum. Пользователи, использующие графические интерфейсы управления пакетами не заметят различий. Для тех кто пользуется средствами управления пакетами из командной строки синтаксис базовых операций сохранится, но будут наблюдаться (http://akozumpl.github.io/dnf/cli_vs_yum.html) отдельные расхождения в расширенных опциях и настройках. В экспериментальном режиме DNF поддерживается в качестве альтернативной системы управления пакетами начиная с Fedora 18. Полный переход на DNF в Fedora 22 становится неотвратимым в связи с миграцией дистрибутива на Python 3, в то время как Yum поддерживает только работу с Python 2.
Пакетный менеджер DNF (https://fedoraproject.org/wiki/Features/DNF) является ответвлением от Yum 3.4, созданный для развития некоторых новых идей, таких как использование в качестве бэкенда для разрешения зависимостей библиотеки hawkey (https://fedoraproject.org/wiki/Features/Hawkey). Для разрешения зависимостей в DNF задействован SAT solver, реализованный в библиотеке libsolv (https://github.com/openSUSE/libsolv) (hawkey выступает в роли надстройки над libsolv), созданной в рамках проекта openSUSE. Для обычного пользователя главными достоинствами DNF является заметно более высокая скорость работы и низкое потребление памяти. Для расширения функциональности DNF предоставляет фиксированный API для плагинов и интеграции с другими приложениями, такими как инсталлятор Anaconda.
URL: https://lists.fedoraproject.org/pipermail/devel-announce/201...
Новость: https://www.opennet.ru/opennews/art.shtml?num=39986
Почему нельзя было просто перевести yum на Python 3 и добавить некоторые фичи? Зачем было создавать форк?
Намекаю на то, что разработчики yum не хотели переходить на Python 3 и добавлять новые фичи, поэтому был создан форк.
"Просто переход на питон 3" ничего не поменяет в области позорной производительности yum. Да и DNF - полумеры.
Если DNF полимеры, тогда apt полное уг.
> Если DNF полимерыХа-ха-ха, ^^^^^ опечатка почти по Фрейду :).
> Да и DNF - полумеры.Вынос всей логики разрешения зависимостей в сишную либу - полумеры?
А вы код Yum видели? Это ж страх и ужас.
> А вы код Yum видели? Это ж страх и ужас.А что, с гвидобейсиком бывает по-другому?
> А что, с гвидобейсиком бывает по-другому?Ничего вы не понимаете! Там не просто гoвнoкод! Там правильно отформатированный гoвнoкод!
Код апта еще хуже. В яме хотя бы 20-летнего легаси, написанного чтобы изучить c++, нет.
Главный разработчик YUM погиб
> Главный разработчик YUM погибПричём насколько понимаю -- это и стало главной причиной...
PS: в смысле "погиб => замена пакетного менеджера", не подумайте чего.
Может быть, иногда действительно легче переписать? Тем более пакетный менеджер не драйвер видеокарт и не фотошоп, обойдётся без большой крови.
> Почему нельзя было просто перевести yum на Python 3 и добавить некоторые
> фичи? Зачем было создавать форк?yum на python3 по-прежнему разрешал бы зависимости сам, а не через сишную библиотеку.
Прирост производительности при таком сценарии пренебрежимо мал.
Понаыдумуют! Ребята учились бы в Arch Linux, конечно система инная, но гпраздо проще всяких там RPM, yum, apt-rpm, urpmi. Зачем себе жизнь усложнять, делайте инструменты попроще, зачем функции которые и не понадобяться?
в том arch, где несколько лет кричали "не нужны нам подписи пакетов"? им самим бы подучиться, есличто
> инная,Какая-какая система? Звучит подозрительно.
> но гпраздо проще всяких там RPM, yum, apt-rpm, urpmi.
Мопед проще боинга. Но почему-то боинги до сих пор производятся.
> Понаыдумуют! Ребята учились бы в Arch Linux, конечно система инная, но гпраздо
> проще всяких там RPM, yum, apt-rpm, urpmi. Зачем себе жизнь усложнять,
> делайте инструменты попроще, зачем функции которые и не понадобяться?Затем, что упрощая жизнь себе -- усложняешь другим. Например, тем, кому лишние гигазы хлама из "полного комплекта" тащить или ещё и собирать это всё на месте.
Из-за этого и отпиливается -dev/-devel.
Дальнейшую нарезку можно долго объяснять на пальцах, это примерно как с fine-grained locking: без него быстро, но только пока мало. В общем, подрастёте -- поймёте сами.
Что только люди не придумывают, чтобы не использовать deb + apt-get
>Что только люди не придумывают, чтобы не использовать ./configure && make && make installfxd
> Что только люди не придумывают, чтобы не использовать ./configure && make DESTDIR=/tmp/pkg-1.0 install-strip && (cd /tmp/pkg-1.0 && find) > /var/db/pkg/pkg-1.0 && cp -a /tmp/pkg-1.0/* /tmp/pkg-1.0/.[!.]* /fxd
>deb + apt-getRPM круче!
чем?
> чем?Чем грузи^W DEB!
Тем, что в отличие от деба, умеет в транзакционность (как метаданных, так и данных). Да и система сборки пакетов поприятнее.
>>deb + apt-get
> RPM круче!Как это относится к apt?
mc круче moc
Apt-get неудобный. Быстрый, в сравнении с yum так и вовсе реактивный, но уже за одно разделение на несколько утилит (типа apt-get и apt-cache) хочется матом обложить.
> Apt-get неудобный. Быстрый, в сравнении с yum так и вовсе реактивный, но
> уже за одно разделение на несколько утилит (типа apt-get и apt-cache)
> хочется матом обложить.Есть aptitude.
> Apt-get неудобный. Быстрый, в сравнении с yum так и вовсе реактивный,И не требует под себя минимум 512 Мб памяти на VM, в отличие от yum.
> Apt-get неудобный. Быстрый, в сравнении с yum так и вовсе реактивный, но
> уже за одно разделение на несколько утилит (типа apt-get и apt-cache)
> хочется матом обложить.Это дело привычки. А само разделение осмысленно тем, что для поиска пакета совершенно не обязательно что-то скачивать с сети.
> Apt-get неудобный. Быстрый, в сравнении с yum так и вовсе реактивный, но
> уже за одно разделение на несколько утилит (типа apt-get и apt-cache)
> хочется матом обложить.Разделения уже нет. Есть один apt.
> Разделения уже нет. Есть один apt.Спасибо, действительно есть. Но с разделением удобнее.
Которой также нужно менять
Да ну его нафиг, он не для людей сделан.
> Да ну его нафиг, он не для людей сделан.Да ты сам то тест Тюринга попробуй еще пройди.
>> Да ну его нафиг, он не для людей сделан.
> Да ты сам то тест Тюринга попробуй еще пройди.scochan.com/thumbs/201406/smallYbX4sp8iUdWP.jpg
ты хоть знаешь что это такое?
Лучше использовать zypper.
Полгода уже пользуюсь DNF. На самом деле намного быстрее разрешает зависимости. Нужен.
> Полгода уже пользуюсь DNF. На самом деле намного быстрее разрешает зависимости. Нужен.Как было бы всем проще, если бы зависимости не пришлось бы разруливать. Вообще.
такая концепция уже есть в программировании, называется внедрение зависимостей http://ru.wikipedia.org/wiki/Dependency_Injection
Действительно будет здорово если эту концепцию как то применить и при установке ПО
Это будет почти как в Windows. Или как в Docker :3
И потом огребать со срочным обновлением не одного глючного продукта (например OpenSSL), а всей системы, с лицензиями, а заодно все пакеты весят в 10-20 раз больше (потому что почитать список зависимостей Вам западло и Вы даже не догадываетесь сколько оно будет весить когда всё это влинкуется)
Injection'ом хорошее дело не назовут
Ну отслеживать-то их всё равно надо. А чтобы не разруливать — уже много раз было. Навскидку вспомню GoboLinux и NixOS (причём оба сейчас живы). Для этого надо просто наплевать на стандартные правила размещения /lib и /bin и ставить каждый пакет в отдельное место ;а потом море symlinks). В принципе, подготовка пакетов для простых программ при этом чуть упрощается.Так что если кому-то действительно кажется, что проблемы с зависимостями и конфликтами — главная проблема, так есть на что перейти. Я вот перешёл на NixOS несколько лет назад.
> ставить каждый пакет в отдельное место ;а потом
> море symlinks). В принципе, подготовка пакетов для простых программ при этом
> чуть упрощается.Mac OS
В MacOS X каждый пакет библиотеки ставится в N мест, где N — количество использующих программ, или я что-то путаю?
Я совсем недавно возился с пакетированием под Mac OSX и выяснил, что там есть 2 метода установки программ:а) Старый, в котором специально сделанный каталог с программой и её библиотеками целиком копируется в /Applications. Каталог должен иметь расширение .app и правильную структуру, тогда ОС может её "открыть".
б) Новый - с инсталлятором.
Первый вариант - это фирменная фишка Mac OS как таковой (даже без X).
В первом случае библиотеки тащатся вместе с программами (и, значит, у каждой программы своя копия библиотеки), а во-втором случае, видимо, возможны варианты. Плюс, есть ещё нормальные системы портов, в которых библиотеки разделяются.
> Mac OSДа, там все почти как в винде - каждый таскает все с собой. И класть хотел на то что его zlib - начала двухтысячных и потому уязвим к эксплойтам. Это потом хомяки будут чесать репу - чего это компьютер глючит? А оказывается, там уже стада автоматической живности нашли дармовой ресурс...
> Ну отслеживать-то их всё равно надо. А чтобы не разруливать — уже
> много раз было. Навскидку вспомню GoboLinux и NixOS (причём оба сейчас
> живы). Для этого надо просто наплевать на стандартные правила размещения /lib
> и /bin и ставить каждый пакет в отдельное место ;а потом
> море symlinks). В принципе, подготовка пакетов для простых программ при этом
> чуть упрощается.
> Так что если кому-то действительно кажется, что проблемы с зависимостями и конфликтами
> — главная проблема, так есть на что перейти. Я вот перешёл
> на NixOS несколько лет назад.Плохо перешел, иначе бы знал, что разруливание зависимостей никуда не исчезло, просто чуть упростилось за счет отсутствия конфликтов и, соответственно, циклов, требовавших обратных проходов по дереву зависимостей
Всем? Не знаю, мне и сейчас не составляет труда смотреть на то, как пакетный менеджер возится с зависимостями при установке пакета. Просто не надо сидеть на Шлаквари в двадцать первом веке.
> Как было бы всем проще, если бы зависимости не пришлось бы разруливать.Используйте slackware - там можно самому разруливать заввисимости. Специально для тех кто любит все на педальном приводе делать. А совсем без учета зависимостей не получится - мало кто нынче пишет программы без использования сторонних библиотек и прочих компонентов.
Не было бы. Вопервых проблемы с реализацией обновлений частей, во вторых сейчас мейнтейнеры пакетов крупных дистров порой подтягивают софт до поддержки актуальных версий библиотек.
А с DNF разрешение зависимостей происходит РЕАЛЬНО БЫСТРО. Даже на моем не самом быстром компе занимает около секунды.
> самом быстром компе занимает около секунды.Надо же, редхатчики начинают понимать за что мы любили deb-based системы столько лет :).
>> самом быстром компе занимает около секунды.
> Надо же, редхатчики начинают понимать за что мы любили deb-based системы столько лет :).Какой вы грамотный человек. Отлично понимаете, что формат пакета и система управления пакетами жестко связаны между собой, а всяких alt linux не существует.
угу, а systemd быстрее стартует, а вяленый без тиринга, а гомнощель вообще крутая как ipad
> угу, а systemd быстрее стартует, а вяленый без тиринга, а гомнощель вообще
> крутая как ipadSystemd действительно быстрее стартует, вяленый без тиринга, а гомнощель вообще крутая как ipad.
Что сказать то хотел?
> Systemd действительно быстрее стартует, вяленый без тиринга, а гомнощель вообще крутая как ipad.
> Что сказать то хотел?Он хотел сыграть на некоторых стереотипах, столь любимых молодым крылом контингента линуксоидов.
http://akozumpl.github.io/dnf/command_ref.html
--version show Yum version and exit
Не понимаю, зачем DNF показывать версию Yum?
> Не понимаю, зачем DNF показывать версию Yum?Особенно, когда Yum нет. :-)
> Не понимаю, зачем DNF показывать версию Yum?Ну что вы как маленький? При копипасте случилась небольшая лажа - не все строки заменили, оказывается. Заведите им баг! :)
yum версию с комментариями авторов dns
emerge-боги смотрят на эти шевеления, как на...
> emerge-боги смотрят на эти шевеления, как на...И каждую неделю релизят; Тут правда Зак пропал - поэтому релизов нету, разработки неты и вообще беда, когда на таком уровне кто то делает в одно рыло
> emerge-баги//fixed :)
Тоже мне бог, мля, который не может затык на 10 секунд в программе отпрофайлить.
Уже побежал возиться с профайлером, ага. Алоглазики такие забавные.
> Уже побежал возиться с профайлером, ага. Алоглазики такие забавные.Я и говорю - гентурасы они такие: понтoв на килограмм, а знаний о работе системы - под микроскопом не разглядишь.
Что мне надо - то я и знаю, я ж не красноглаз, чтобы ползать по системе вдоль и поперёк, лол.
> я ж не краснoглаз,Это с гентой то? А для чего еще генту ставить можно? Ну разве что для того чтобы перед одноклассниками покрасоваться?
C - напиши программу и используй её следующие 30 лет.
Python - напиши программу и отправь её в мусорку через три года.
> Python - напиши программу и отправь её в мусорку через три года.Python - напиши программу и переписывай ее каждые 2 года в течение 20 лет :).
> C - напиши программу и используй её следующие 30 лет.вот эт кто-то размечался на славу :-)
если даже предположить что ты не попадёшь на случаи прямой несовместимости (например переменная случайно называется также как и ключевое слово которое появилось в новой версии синтаксиса языка) -- то уж мечтать о том что API-библиотек не поменяется в течении пару лет -- это реально не более чем чьи-то грёзы :-)
> вот эт кто-то размечался на славу :-)А что - размечтался? Вон например компрессоры LZ(W/H/...) - собираются и поныне. Даже винтажные экспонаты начала 90-х, если не конца 80-х. Им более 20 лет как раз долбануло.
> если даже предположить что ты не попадёшь на случаи прямой несовместимости (например
> переменная случайно называется также как и ключевое слово которое появилось в
> новой версии синтаксиса языка)Вообще ни разу такие фокусы не попадались. Скорее, новые компилеры лучше анализируют код и икают warning-ами на потенциально проблемные места. Но компилят. И работает.
> -- то уж мечтать о том что API-библиотек не поменяется в течении пару лет -- это
> реально не более чем чьи-то грёзы :-)В нормальных библиотеках API как раз достаточно стабильный. А что, часто менялся апи у какого-нибудь open()? Или даже пусть у zlib? Или там libpng, если мы хотим картинки читать/писать?
> переменная случайно называется также как и ключевое слово которое появилось в новой версии синтаксиса языкаЕщё один не отличает C от C++.
Стандарт C++ тоже каждые два года меняется, так что тут он больше похож на питон чем на си.
> Стандарт C++ тоже каждые два года меняется, так что тут он больше
> похож на питон чем на си.Обратная совместимость, всё-таки, поддерживается.
и что, программа написанная лет 10 назад не компилится? и не работает?
> C - напиши программу и используй её следующие 30 лет.
> Python - напиши программу и отправь её в мусорку через три года.Можно было на Ocaml написать - примерно тот же Python, только со статически проверяемой типизацией (вывод типов) и обратной совместимостью, да скоростью в 0.5 от оптимизированного С++.
То-то 20-летний плюсовый г*внокод в apt, отвечающий за pinning, уже лет 15 хотят переписать, но боятся сильно трогать.
OpenSuSE задаёт тренд. ALTLinux, к примеру, запилила deepsolver.
> OpenSuSE задаёт тренд. ALTLinux, к примеру, запилила deepsolver.Их, видимо, Леня покусал. Нет, чтобы оттестированный libhawkey взять, так нет, обязательно надо свое сделать.