LINUX.ORG.RU

В Fedora 22 по умолчанию будет пакетный менеджер DNF

 ,


0

0

DNF является форком Yum. DNF был создан в январе 2012 года и был доступен для экспериментов в Fedora начиная с версии 18. Тем самым разработчики хотят использовать DNF по умолчанию в новой версии Fedora 22.

На практике данное изменение означает:

  • Anaconda устанавливает систему используя пакетный менеджер DNF (без специальных переключателей)
  • Пакет DNF будет по умолчанию установлен.
  • Пакет «dnf-yum-compat-command» так же будет установлен по умолчанию, данный пакет является скриптом который перенаправляет /usr/bin/yum на /usr/bin/dnf с соответствующим сообщением, что DNF является предпочтительным менеджером пакетов.

Это изменение будет полностью прозрачным для пользователей, которые используют только графические инструменты управления пакетами. Для тех кто использует командную строку, будут некоторые различия по сравнению с Yum, но все важные операции будут спокойно доступны c DNF, используя тот же синтаксис CLI.

>>> Рассылка

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Poisoned (всего исправлений: 2)

Ответ на: комментарий от Lincor

Принципиально новый лисапед с более качественной тормозной системой.

Valkeru ★★★★
()
Последнее исправление: Valkeru (всего исправлений: 1)

На сколько я понял, то у него более быстрая нежели с офтопиком скорость разрешения зависимостей

SilverFreez
()

Пакет DNF будет по умолчанию установлен.

Вроде, давно уже.

Давно бы перешел на него, если dnf имел общую с yum'oм историю установленных/удаленных пакетов.

aplay ★★★★★
()

Нужно почитать.

dada ★★★★★
()

юм - один из популярнейших пакетных менеджеров
его развитие пойдет только на пользу всей линейке редхатовских дистрибутивов

kto_tama ★★★★★
()

Вот когда появится форк DNF тогда и буду юзать

Xegai ★★
()
Ответ на: комментарий от King_Carlo

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

Black_Roland ★★★★
()

питон на питон? нее, спасибо.

не надо.

vitalikp
()

Новость о намерениях сделать что-то дефолтом в послеследующем релизе? fallout4all, а чего не в Толксах?

aidan ★★★★
()
Ответ на: комментарий от King_Carlo

А yum типа разруливает медленно и кто-то от этого страдает?

По-моему, при использовании yum страдает любой, кто когда-нибудь видел apt.

Moonshine
()

Этот DNF очень часто падает в текущей fedora rawhide. Особенно при поиске пакетов.

MLP_Fan ★★
()
Ответ на: комментарий от King_Carlo

А yum типа разруливает медленно и кто-то от этого страдает?

Юзеру, который набирает юм апдейт апгрейд и уходит пить чай или на вкладку браузера, пофигу.

Инженерам, которые разворачивают сотни виртуалок автоматически для тестирования ПО, например, не пофигу.

sT331h0rs3 ★★★★★
()
Ответ на: комментарий от Lincor

он на третьем пистоне, который теперь дефолтный

xsektorx ★★★
()
Ответ на: комментарий от anonymous

закопайте не нужно apt

Запятую поставить по своему усмотрению.

Zubok ★★★★★
()
Ответ на: комментарий от Lincor

Какие киллер фичи могут быть у софта написанного на python?

bhfq ★★★★★
()
Ответ на: комментарий от Moonshine

По-моему, при использовании yum страдает любой, кто когда-нибудь видел apt.

Который не умеет игнорировать зависимости, и лучше знает какие пакеты вам нужны. А, если вы начнёте умничать, и принудительно удалять через --force-all, то при первом-же обращении к apt он вам это припомнит, и не даст ничего сделать пока вы не вернёте (или не удалите по зависимостям) всё на место.

anonymous
()
Ответ на: комментарий от sT331h0rs3

Инженерам, которые разворачивают сотни виртуалок автоматически для тестирования ПО, например, не пофигу.

Подготовить одну ВМ и клонировать, не?

King_Carlo ★★★★★
()
Ответ на: комментарий от King_Carlo

А ставить туда специфичный для каждого теста набор софта, не?

sT331h0rs3 ★★★★★
()
Ответ на: комментарий от King_Carlo

Подготовить одну ВМ и клонировать, не?

Оне не умеют.

anonymous
()

Прошлый велосипед разработчикам видимо надоел, решили сделать новый.

umren ★★★★★
()

Чтобы тут не было много флуда. Вот некоторые из фич.

* более быстрый резолвинг зависимостей (библиотека libsolv на С)
* более просто писать плагины. Да и уже куча написана. https://github.com/akozumpl/dnf-plugins-core
* имеет хорошую документацию.

i_gnatenko_brain

anonymous
()

Все это невозможно реализовать без тотального переписывания. К тому же это надо еще параллельно тестировать. Ечли 2 разных названия - проще держать в системе. Да и зачем переписанному софту иметь старое имя? Dandified Yum.

А если я расскажу на лоре о том, что есть новый стандарт. AppStream. И пора бы внедрять в приложения. Все скажут не нужно? Мол у нас есть описания в рпм/деб.

i_gnatenko_brain

anonymous
()

Почитывал недавно рашн федору, писали про недостатки RPM-пакетов. Первая мысль - пришли новые программисты и нашли «фатальный недостаток». Но потом я перечитывал новость про RHEL 5 на ЛОРе, и в комментариях узнал что об этих недостатках известно уже давно. Поэтому желаю удачи проекту.

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от anonymous

Который не умеет игнорировать зависимости

В отличие от Fedora в Debian и клонах есть рекомендуемые зависимости, которые можно проигнорировать, если хочется. Если же зависимость жёсткая, значит, этот пакет необходим. Так что ломать зависимости просто не нужно. (А для особо одарённых есть equivs.)

А, если вы начнёте умничать, и принудительно удалять через --force-all, то при первом-же обращении к apt он вам это припомнит, и не даст ничего сделать пока вы не вернёте (или не удалите по зависимостям) всё на место.

Задача менеджера пакетов - поддерживать пакетную систему в согласованном состоянии. Так что такое поведение абсолютно корректно.

anonymous
()
Ответ на: комментарий от anonymous

А, если вы начнёте умничать, и принудительно удалять через --force-all, то при первом-же обращении к apt он вам это припомнит, и не даст ничего сделать пока вы не вернёте (или не удалите по зависимостям) всё на место.

Задача менеджера пакетов - поддерживать пакетную систему в согласованном состоянии. Так что такое поведение абсолютно корректно.

Такое поведение оправдано, но не «абсолютно корректно» - практически всегда сломано только поддерево зависимостей, и пакетный менеджер должен уметь работать на тех поддеревьях, что не сломаны.

tailgunner ★★★★★
()

Да здравствует NIH! Релиз RHEL7 состоялся, так что ближайшие 3-4 года сообщество федоры может снова начинать активно переписывать системные компоненты.

jekader ★★★★★
()
Ответ на: комментарий от anonymous

В отличие от Fedora в Debian и клонах есть рекомендуемые зависимости, которые можно проигнорировать, если хочется.

Не знаю как в Fedora, а в SuSE штантыми средствами ПМ можно игнорировать не только рекомендуемые зависимости, но так же и жёсткие (да и вообще что угодно) — главное хорошо понимать что и как работает, и без чего можно прекрасно обойтись не смотря на то, что об этом думает майнтейнер.

Если же зависимость жёсткая, значит, этот пакет необходим. Так что ломать зависимости просто не нужно.

Это вам так кажется. Вот к примеру возьмём Ubuntu (самый наверное выдающийся по части идиотских зависимостей) дистрибутив. Очень мне мешает прибитый гвоздями ibus. Мало того, что он мне просто не нужен, так он ещё и перебивает некоторые вещи связанные с раскладками. Желаю я его к примеру удалить, просто удалить и всё, без всяких оговорок, т.к. я не вижу ни одной причины по которой он должен быть оставлен. Набираю я:

# apt-get purge ibus
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  cups-pk-helper gnome-control-center gnome-control-center-data gnome-control-center-shared-data libgnome-control-center1 libgoa-backend-1.0-1 mousetweaks python-cupshelpers
  system-config-printer-common system-config-printer-gnome system-config-printer-udev
Suggested packages:
  gstreamer0.10-pulseaudio
The following packages will be REMOVED:
  ibus* unity-control-center*
The following NEW packages will be installed:
  cups-pk-helper gnome-control-center gnome-control-center-data gnome-control-center-shared-data libgnome-control-center1 libgoa-backend-1.0-1 mousetweaks python-cupshelpers
  system-config-printer-common system-config-printer-gnome system-config-printer-udev
0 upgraded, 11 newly installed, 2 to remove and 188 not upgraded.
Need to get 2 458 kB of archives.
After this operation, 9 972 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
… даже комментировать это не хочу. И это только чтастный случай, а лишнего мусора в этом дистрибутиве установливается просто более половины от полезного софта.

(А для особо одарённых есть equivs.)

Это «особо одарённые» его придумали, которые прадлагают заменять идиотские зависимости пустышками, вместо того, чтобы просто добавить в ПМ опцию «игнорировать», (есть наверное практически везде, кроме deb-based).

anonymous
()
Ответ на: комментарий от dexpl

Хвалить apt вообще может только тот, кто ни с yum, ни c apt вплотную не работал и потому из всех критериев для сравнения знает только время скачивания метаданных (которое в yum тоже можно отключить).

Тогда как если взяться за сборку пакетов, управление репозиториями, да даже банальный yum provides, то тут просто небо и земля.

alpha ★★★★★
()
Ответ на: комментарий от dexpl

Вопрос: как в apt получить имя пакета (из репа, а не только из установленных), в котором содержится бинарь, матчащийся заданной маской?

pianolender ★★★
()

Принципиально новый велосипед, теперь с треугольными колёсами. Интересно, чем их yum не устраивает? Работает же отлично, ничего не тормозит, функционал на высоте...

Lennox ★★★★★
()
Ответ на: комментарий от pianolender

Вопрос: как в apt получить имя пакета (из репа, а не только из установленных), в котором содержится бинарь, матчащийся заданной маской?

Ты меня экзаменуешь или правда не знаешь? Ответ — в 3 команды, первая из которых устанавливает доп. утилиту. Для сравнения, в yum это одна команда — yum provides pattern.

dexpl ★★★★★
()
Ответ на: комментарий от Lennox

Интересно, чем их yum не устраивает?

название плохо рифмуется с их новой системой сборки COPR

BMX ★★☆
()
Ответ на: комментарий от dexpl

Извиняюсь, перепутал направление ваших поредпочтений. Мне тоже больше нравится, как в yum сделано. А что именно там за дополнительная утилита?

pianolender ★★★
()
Ответ на: комментарий от pianolender

Извиняюсь, перепутал направление ваших поредпочтений.

OK. И давай на ты, угу?

А что именно там за дополнительная утилита?

apt-file

dexpl ★★★★★
()
Ответ на: комментарий от spichka

Нет. В какой-то мере это восполняется возможностями autoremove, но только в какой-то мере.

У меня сейчас беда с аналогами yumdownloader ещё. То есть с их отсутствием.

Чтобы скачать пакеты с зависимостями из нестандартных репозиториев, в RPM-мире достаточно использовать yumdownloader -c another_yum.conf. Что приходится делать в deb — это просто уму непостижимо.

alpha ★★★★★
()
Ответ на: комментарий от novitchok

я смотрю, у тебя-то с аптом всё шоколадно, да.

По ссылке проблема с aptitude.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Который не умеет игнорировать зависимости

Всю жизнь игнорил зависимости в apt и успешно удалял.

Shadow ★★★★★
()
Ответ на: комментарий от tailgunner

поддерево зависимостей

Граф зависимостей не является деревом, ибо допускает циклы.

пакетный менеджер должен уметь работать на тех поддеревьях, что не сломаны.

Это только на словах просто, типа «надо делать хорошо и не делать плохо». Полностью игнорировать «сломанную» компоненту связности не получится, ибо, например, возможна такая ситуация:

  • Вы запросили установку пакета.
  • Этог пакет зависит от пакета, находящегося в «сломанном» подграфе.

Корректно разрешить такие ситуации нельзя, можно лишь сразу заворачивать любые попытки связи со «сломанным» подграфом, но учитывая большое количество возможных связей (помимо традиционных Depends и Recommends это и Breaks, и Conflicts, и Pre-Depends, и Replaces, и Provides...), подобное усложнение алгоритма приведёт к мизерной выгоде.

Кроме того, есть ещё и неочевидные связи: скажем, удаление пакета может привести к изменению конфигурации системы альтернатив, переключив одну на «сломанный» пакет: система альтернатив не относится к пакетному менеджеру и ничего не знает о зависимостях.

Есть и ещё подсистемы, работающие в условиях предположения о корректности состояния пакетов.

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.