Доступен релиз пакетного менеджера DNF 4.6, который используется по умолчанию в дистрибутивах Fedora Linux и RHEL 8. DNF является ответвлением от Yum 3.4, адаптированным для работы с Python 3 и использующим библиотеку hawkey в качестве бэкенда для разрешения зависимостей. По сравнению с Yum, DNF обладает заметно более высокой скоростью работы, низким потреблением памяти и более качественным управлением зависимостями...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54483
> По сравнению с Yum, DNF обладает заметно более высокой скоростью работыСтесняюсь спросить, а Yum получается вообще не работал? Просто мне трудно представить что-то более тормозное чем DNF.
> Стесняюсь спросить, а Yum получается вообще не работал?Работал, но потреблял больше памяти и дольше ресольвил (впрочем, заметно разве что на сверхдешевых VPS или при глобальном обновлении версии дистрибутива).
> Просто мне трудно представить что-то более тормозное чем DNF
Эм. А что именно тормозное? Резольвинг через libsolv - так он нынче почти во всех rpm-based используется. Применение deltarpm? Сама установка пакетов? Так это внутри librpm делается, там много всяких действий (контрольные суммы и тп..).
Задача "установить пакет или пачку обновлений" обычно выполняется за 3-4 секунды в dnf...
Он действительно больше думает и тяжелее, чем pacman и apt, но видя разницу в "интеллекте" и функционале, достаточно простительно. Ну ещё может быть человек не настроил толком dnf, сам не пойму, почему майнтейнеры не поменяют параметры по умолчанию на что-то более адекватное, хотя это совершенно безопасно
А как правильно настроить dnf?
> А как правильно настроить dnf?Отключить delta rpm если канал широкий?..
> А как правильно настроить dnf?Путем замены на apt :P
Спасибо, ненужно)
DNF Configuration Referencehttps://dnf.readthedocs.io/en/latest/conf_ref.html
Кури. Всё написано и разжёвано.
А где раздел "Правильная настройка dnf"?
Мозги себе настрой правильно сначала.
>Он действительно больше думает и тяжелее, чем pacman и apt, но видя разницу в "интеллекте" и функционале, достаточно простительноЗачем сравнивать няшу пакмана и apt, который небось тоже на пистоне накалякан... по крайней мере работает с такой скоростью
Кстати, вы забыли написать, что пакман не умеет ) из того, что нужно на десктопе (на серверы мы арч всё равно не ставим)...
Хватит людей троллить, толсто слишком, они не поймут.
Так то он быстрый, но по любому чиху скачивает какие-то метаданные, что, собственно, и производит впечатление, что dnf "тормознутый".
> Так то он быстрый, но по любому чиху скачивает какие-то метаданные, что,
> собственно, и производит впечатление, что dnf "тормознутый".Ааа! Так вот вы про что. Но так это имеет смысл если делать update. Чем это хуже, чем двухэатпный apt-get update / upgrade?
А устаноавливать новый пакет обычно не так часто нужно, чтобы это парило. Но если канал медленный, то есть два решения: или увеличить таймаут до того, как кэш заэкспайрится, либо использовать современный дистрибутив, где есть сервис, каждые несколько часов подтягивающие те самые метаданные в фоне, чтобы при ручном вызове они всегда были актуальные.
Правда, само подтягиватся только базовая информация о пакетах для операций update / install по имени пакета или provides зависимости. Полные метаданные для установки по имени внутри пакета (типа dnf install /usr/bin/some-cool-binary) тяжеловаты и нужны не так часто, их придется тянуть..
yum-cronа вот нахрена было yum переименовывать в dnf не понимаю, ну выпустили бы мажорную версию и всё
> а вот нахрена было yum переименовывать в dnf не понимаю, ну выпустили бы мажорную версию и всёhttps://developers.redhat.com/blog/2016/08/30/why-red-hats-n.../
Так то и питон не тормозит, если ничего не делает... а это быстрое минимум 512 мегов на виртуалке требует, иначе кадавр лопается. С брызгами, убивая свои базы наповал.
> мне трудно представить
> что-то более тормозное чем DNF.Представьте, что каждое чтение БД установленных пакетов с правами root вызывает перестройку индексов и сохранение их с последующим fdatasync. Вся система при этом встаёт колом на некоторое время. 1ГБ обновлений устанавливается 3 (три) часа (на SSD). Разработчики про это не знают, поскольку у них в виртуалочке проблема не проявляется. А когда узнают, ничего не могут поделать, кроме как сгрузить решение проблемы на пользователей. Это называется RPM5 в Rosa Tresh.
Что за бред про RPM5 и три часа на SSD?
4,8 ГБ на HDD SATA2 менее 20 минут ставится на Core2Duo E7300.
Ну а чтобы система висела колом, ее надо было ставить на первые Atom и 512 МБ ОЗУ с диском на USB.
> Что за бред про RPM5 и три часа на SSD?Я не специалист по таким диагнозам. Знаю лишь, что для активистов Rosa характерно отрицать объективную реальность, не имея о ней представления.
> 4,8 ГБ на HDD SATA2 менее 20 минут ставится на Core2Duo E7300.
А ты удали вот этот патчик https://abf.io/import/rpm/commit/4fb14f47db87dd2bbc693befc54...
который Алзим подобрал с форума 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
>> По сравнению с Yum, DNF обладает заметно более высокой скоростью работы
> Стесняюсь спросить, а Yum получается вообще не работал? Просто мне трудно представить
> что-то более тормозное чем DNF.Работал, более того ещё чуть меньше года назад, когда я ставил федорку натыкался на то, что ни их замечательный гуёвый пакетник не находил нужного мне пакета, при том что он был в подключённом репозитории, ни DNF, а вот работающие ещё в то время команды Yum - находили, почему так - без понятия, я не стал разбираться, потому что федорка не мой основной дистр, просто пришлось его поюзать. Никого ни в чём не обвиняю, ничего не ожидаю, просто занятный факт был для меня.
>[оверквотинг удален]
>> Стесняюсь спросить, а Yum получается вообще не работал? Просто мне трудно представить
>> что-то более тормозное чем DNF.
> Работал, более того ещё чуть меньше года назад, когда я ставил федорку
> натыкался на то, что ни их замечательный гуёвый пакетник не находил
> нужного мне пакета, при том что он был в подключённом репозитории,
> ни DNF, а вот работающие ещё в то время команды Yum
> - находили, почему так - без понятия, я не стал разбираться,
> потому что федорка не мой основной дистр, просто пришлось его поюзать.
> Никого ни в чём не обвиняю, ничего не ожидаю, просто занятный
> факт был для меня.Да, и DNF субъективно выглядел увереннее, я надеюсь его допилят, однако, как говориться "fuck'Т налицо"
По моему личному опыту прикол вот в чём:dnf list hren* - может найти "хрень" со товарищи в репозитории, а может и не найти. хз почему. У yum`а реально с этим проблем не было.
dnf list "hren*" - работает 100%.
Так что, обычно по привычке использую первый вариант (без кавычек). А если не срабатывает, использую второй. :)
Логичнее было бы переприучаться ко второму, чтоб время не тратить :).
Передрессировываться. Все эти вкручивания то dnf, то wayland, то systemd, то npf напоминают навязывание ношения масок: "ой-ой, без этого ваще капец, ваши линуксы съедят ужасни ксакепы!!!"
Так федора оно полигон, так чтА..:)
> dnf list hren* - может найти "хрень" со товарищи в репозитории, а может и не найти. хз почемуТссс! Я вам по секрету расскажу, почему.
Потому что * раскрывает bash, а не dnf (у нас все ж таки не ms dos тут, ага). И если у вас в текущем каталоге есть файлик hrenovina.txt, то команда (невидимо для вас) башем превращается в dnf list hrenovina.txt - и он не найдет.
А при экранировании * видит сам dnf.
Но если вы думаете, что тут есть какая-то роль самого dnf, то сильно заблуждаетесь..
> Потому что * раскрывает bash, а не dnf (у нас все жА кто вам сказал, что у товарища выше - bash?
>> Потому что * раскрывает bash, а не dnf (у нас все ж
> А кто вам сказал, что у товарища выше - bash?Да пусть хоть csh у него. Любой юникосвый шелл так делает. Это часть POSIX.
О, спасибо! Ваше объяснение очень похоже на правду.
Но, честное слово, почему-то за yum`ом я такого поведения не помню. Быть может, потому, что yum`ом пользовался уже достаточно давно.
> По моему личному опыту прикол вот в чём:
> dnf list hren* - может найти "хрень" со товарищи в репозитории, а
> может и не найти. хз почему. У yum`а реально с этим
> проблем не было.
> dnf list "hren*" - работает 100%.
> Так что, обычно по привычке использую первый вариант (без кавычек). А если
> не срабатывает, использую второй. :)Возможно вы правы и дело обстоит именно так, и возможно мне бы это помогло, я просто как-то не сообразил за подобную специфику, потому как привык немного к другому поведению, в любом случае я за прирост скорости, без потери функционала и без выжирания дополнительных ресурсов, надеюсь DNF в итоге будет достойной заменой.
Так это ж шеллопроблемы. У меня точно также на zsh не хочет работать без кавычек.
> Просто мне трудно представить что-то более тормозное чем DNFzypper
>> Просто мне трудно представить что-то более тормозное чем DNF
> zypperА вот не надо, zypper кстати довольно неплох, в отличии от самой среды где он используется))
>DNF является ответвлением от Yum 3.4, адаптированным для работы с Python 3Из описания получается что это менеджер питоновских пакетов.
Базовый обязательный софт операционки на питоне - ну такое.
На смеси перла с башем всяко лучше, конечно (см. дебиан)
На C++ не хотел? А таки dpkg и apt именно на этом. Перловка там очень сильно сбоку, в всякой вспомогаловке типа debconf. И то есть cdebconf.
Так и в dnf все по факту на C. Ресольвит через libsolv, качает через librepo, ставит через librpm. А на питоне только клей для связки этих компонент (впрочем, есть у кого-то желание и от клея уйти в пользу чисто сишного libdnf, делающего все это).
В gentoo portage на питоне.Работает - и слава богу.
Что только не делают, лишь бы не юзать дебиан или убунту с божественным apt
apt update && apt upgrade && apt install zolupa VS dnf install zolupa ??
Немного некорректное сравнение. apt update && apt upgrade && apt install zolupa vs dnf upgrade --refresh -y && dnf install zolupa.
Did Not Finish//шапка о5
Спасибо yum и dnf. Если бы не это УГ, я бы никогда не поставил убунту и дебиан, и не узнал бы что оказывается можно и намного лучше пакетные менеджеры писать.
Рассказывайте дальше про днище под названием apt/deb, которые лёгким движением руки делают работу с пакетной базой невозможной. Как минимум по пять раз в неделю болезненные на дистрах на основе deb создают слезливые темы на unix.stackexchange.com по поводу того, что "ничего не могу сделать - вылазят ошибки от apt".Единственный способ поломать RPM базу - это запуск rpm --nodeps или подключение кривых сторонних неподдерживаемых реп (честно говоря, есть и другие способы, но это для power users, например флаги --justdb/--noscripts). А вот APT/DPKG ломаются из коробки. dpkg -i packet.deb с радостью всё ставит(!), даже если нарушены зависимости.
Я уже молчу, что у DNF есть мощнейшие средства по откату и фиксу прерванных транзакций - от чего APT просто умирает.
Так же люб дорог apt remove, который почему-то оставляет пакеты в базе. Зачем сделали purge - не ясно. rpm -e/dnf remove - тупо удаляет всё, кроме изменённых конфигурационных файлов. Никакого мусора в базе RPM.
А, и обновление ядра в Debian дистрибутивах - это отдельная боль.
Короче, я использую Fedora со времён RedHat 5.0 (нет, нет, не RHEL 5, а RedHat 5.0) и ни разу не имел проблем с RPM и обёртками для него (yum/dnf и что-то до них было - уже не вспомню).
Единственная периодическая проблема - это факапы мейнтенеров пакетов в Fedora, но это случается раз в год, не чаще, и ничего не ломает. Например, мне пришлось отложить обновление на F33 на три месяца, потому что Electrum не ставился, но там проблема была даже не с Fedorа, а с поносом, в который превратились Python модули: https://github.com/spesmilo/electrum/issues/6538
На OpenNet недавно была новость, что все дистрибутивы Линукса от этого страдают (Python/NPM/Ruby модули и приложения с дикими зависимостями).
// b.
Блин, пропустил три запятые - прошу прощения.
> лёгким движением руки делают работу с пакетной базой невозможной.У меня проблемы с чем-то таким были 1 раз за 15 лет, к тому же он сам подсказал как чинить. А вот с редхатом это уг при допустим OOM (к которому прожорливая питонятина довольно склонна, особенно в плотно набитых vm и контейнерах) норовит базе харакири сделать. И нет, это уг не скажет как чинить. При этом вообще ничего не сносится и не ставится, прикольничек.
> Как минимум по пять раз в неделю болезненные на дистрах на основе deb создают
> слезливые темы на unix.stackexchange.com по поводу того, что "ничего не могу
> сделать - вылазят ошибки от apt".Для начала это потому что этих болезных на пару порядков больше. Видите ли дебианообразных реально еще и как десктоп юзать. В отличие от редгадов, которые в этом качестве годятся только унылым корпам и прочим некромантам. Как вариант тем кто мечтает побыть лабораторной крысой с федорой. Промежуточных вариантов там просто нет.
> Единственный способ поломать RPM базу - это запуск rpm --nodeps или подключение
> кривых сторонних неподдерживаемых репИли просто OOM огрести. Не дай боже VM менее 512 памяти сделать или сервис какой запустить, кадавр лопается с брызгами. И уж базу при OOM убивает чуть не 50/50.
В итоге демьян реально даже на vm с 64..128 мегов vm гонять, без свопа, а этого жирного урода... так что при прочих равных на демьяне виртуализовано-изолированное окружение сильно легче получается. Оплачивать гамнокодиниг питономакак из рхел мне не с руки. А за столько лет можно было и нанять пару плюсовиков уже чтоли, дебианщики даже нашару как-то проскочили вон.
> из коробки. dpkg -i packet.deb с радостью всё ставит(!), даже если
> нарушены зависимости.Это низкоуровневый инструмент для тех кто понимает что и зачем делает.
> Я уже молчу, что у DNF есть мощнейшие средства по откату и
> фиксу прерванных транзакций - от чего APT просто умирает.Я уже заметил, с DNF случается то же что с MSI. На середине его убивает oom и он ни откатить, ни доделат. И база убита напопал - так что остальные программы тоже снеси или поставить не выйдет.
> Зачем сделали purge - не ясно.
Кто ж читает маны то? Remove оставляет конфиги и т.п., на случай если программу может захотеться переставить. Purge - полный вынос, после реинсталла коли такой будет задуман "жесткий" сброс на дефолты.
> А, и обновление ядра в Debian дистрибутивах - это отдельная боль.
Не заметил никакой боли. Напротив очень крутой и гибкий механизм при том что оформлено пакетом на общих основаниях. А хуками таки можно даже на махровом embedded в флеху зашить новое ядро, если оно надо. Т.е. это даже не в ФС может быть - лишь бы то что вызвано хуком знало что делать.
> Короче, я использую Fedora со времён RedHat 5.0
Нафиг надо быть лабораторной крысой...
> а с поносом, в который превратились Python модули:
Да собственно питон весь - это самое. И ну его нахрен в пакетном менеджере.
> // b.
А, ну это то известный эксперт по линуксам. Случайно не коллега/альт поха?
512MB OOM?Болезненный, вы пытались без свопа F33 гонять с таким объемом RAM на VPS? Сочувствую. Системные требования F33 сказать или сами найдёте?
За 25 лет использования RPM с обёртками не видел OOM ни разу.
Темы по поводу поломанного apt'a тем временем появляются постоянно и часто, а на dnd/rpm что-то не жалуются.
Брехню и извращения оставьте при себе.
А тема с ядрами: это то, что убунта до недавнего времени автоматом ставила ядра без удаления старых версий, пока не забивала /boot и не ломала обновления.
Сказочники, короче. Вылез.
Тьфу ты.
// b.
> Болезненный, вы пытались без свопа F33 гонять с таким объемом RAM на
> VPS? Сочувствую. Системные требования F33 сказать или сами найдёте?Да спасибо, у меня дебианы, вон даже 128 без свопа есть, изолирует 1 конкретный сетевой сервис от остального. Нормалек? :)
> За 25 лет использования RPM с обёртками не видел OOM ни разу.
Я не нанимался платить за криволапость питоноиндусов редхата более дорогими тарифами хостеров.
> Темы по поводу поломанного apt'a тем временем появляются постоянно и часто, а
> на dnd/rpm что-то не жалуются.Его юзают на пару порядков чаще. В том числе и потому что прекрасно живет на младших тарифах у жадных хостеров.
> Брехню и извращения оставьте при себе.
Я и оставил - изоляция отдельных сервисов в виртуалки мне нравится, равно как и копеечные тарифные планы.
> А тема с ядрами: это то, что убунта до недавнего времени автоматом
> ставила ядра без удаления старых версий, пока не забивала /boot и
> не ломала обновления.И эти люди еще что-то там про системные требования рассказывают.
> // b.
Эксперт мирового класса вылез. Помнится эксперт с такой подписью вообще на линукс фекалии лил, насколько я помню.
> dnf remove - тупо удаляет всё, кроме изменённых конфигурационных файлов.Не всегда. Несколько раз замечал, что dnf remove иногда может удалить не все пакеты, вдобавок dnf autoremove потом их не подчищает, делать же dnf history undo <номер_транзакции> тоже не всегда вариант, особенно если транзакция древняя и с тех пор зависимые пакеты по сто раз обновились.
Столько г0вна вылито на DNF - вы им когда последний раз пользовались?У меня Core i5 ULV от 2015 года со сверх дырявым SkyLake:
dnf update
раз в день-два занимает несколько секунд, при этом обновляя по 5-20 пакетов на Fedora 33.
Да, с deltarpm оно может очень долго работать (это только стадия delta), но deltarpm стоит использовать только тем, у кого трафик либо дорогой, либо канал медленный. DeltaRPM, кстати, by default выключен уже два релиза подряд.
Короче, вонь идёт, судя по всему от тех, кто Fedora запускал лет 10 назад. Дистрибутив сейчас очень быстрый, кроме анальных флагов компиляции для GCC и SeLinux=on by default. Увы, либо безопасность, либо скорость - если Вам последнее, то Gentoo/LFS в руки. А Fedora - это testbed для RHEL, для которой безопасность - на уровне безоговорочного требования.
// b.
> Столько г0вна вылито на DNF - вы им когда последний раз пользовались?1. И по делу. Ведь можно такое и на bash зафигачить, бгг.
2. НЕ пользовались и НЕ собираемся ;)
Не пользовался (или пользовался лет 10 назад), не видел, но осуждаю™.Суть большинства ответов в теме.
// b.
> Суть большинства ответов в теме.Это интуитивно понятно, друхх, как например то, что наступать на крышку люка не стоит)) + камент ниже.
Просто критики не в курсе за dnf makecache (чит. их любимое apt-get update), пишут с лету dnf install someshit и залипают на обновление реп)))
Петон? -> Попса, "промышленный быдлокод"? Не видели вы zypper'а))
> Петон? -> Попса, "промышленный быдлокод"? Не видели вы zypper'а))А зачем на них смотреть когда есть дебиан и apt :)
И чем же так хороша структура дебиановских репозиториев? Помимо, собственно, пакетов там гора каких-то левых каталогов и файлов, назначение которых совершенно непонятно. По дюжине версий одного и того же приложения, например, миднайт-коммандер представлен всеми версиями c 2014 по 2021 годы. Это не репозиторий, а помойка.