форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yum"	+/–
Сообщение от opennews (??) on 12-Май-15, 00:44
Анонсирован (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.dev/opennews/art.shtml?num=42209
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+14 +/–
Сообщение от Аноним (??) on 12-Май-15, 00:44
> Увидел свет пакетный менеджер DNF у меня дежавю? :-) ...или это уже какой по счёту раз?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+10 +/–
	Сообщение от Анончег on 12-Май-15, 02:00
	> у меня дежавю? :-) ...или это уже какой по счёту раз? Эх, ты! Радоваться надо, смотри сюда: "Новый выпуск также примечателен поддержкой работы с репозиториями, использующими HTTP basic-аутентификацию." Ты хоть представляешь, что сие означает - это же прорыв, прорыв в неизведанное! Самое последнее слово в обеспечении безопасности!
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	17. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+5 +/–
	Сообщение от Аноним (??) on 12-Май-15, 09:01
	> "Новый выпуск также примечателен поддержкой работы с репозиториями, использующими HTTP basic-аутентификацию." Новый выпуск также примечателен поддержкой работы с репозиториями FIXED
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	47. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Sergey722 (ok) on 13-Май-15, 09:00
	> Самое последнее слово в обеспечении безопасности! Согласен, последние времена настают...
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

2. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	–9 +/–
Сообщение от Аноним (??) on 12-Май-15, 00:52
Слушайте, а почему не напишут на C/C++ или на GO? Давно ведь проситься, а то ведь питон же уходит в лету с каждой секундой.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	–3 +/–
	Сообщение от Xasd (ok) on 12-Май-15, 00:58
	может ещё и на C# написать попросишь? :-) Python самое то -- для задач административных утилит! потому как чуть менее примитивный чем кривой Bash, и на много проще чем компилируемые языки
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	5. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+10 +/–
	Сообщение от Аноним (??) on 12-Май-15, 01:41
	zypper на плюсах написан, и ничего, работает, питона в зависимостях не просит...
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	7. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Анончег on 12-Май-15, 02:03
	> zypper на плюсах написан, и ничего, работает, питона в зависимостях не просит... Так это же ретроградная поделка, то ли дело Петон - современно, надёжно, молодёжно.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	15. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+3 +/–
	Сообщение от anonymous (??) on 12-Май-15, 07:39
	Питону уже сто лет в обед. А модно и молодёжно - это гоу, раст и им подобные.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	29. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	–1 +/–
	Сообщение от Аноним (??) on 12-Май-15, 17:29
	Бздшный pkg вообще на Сях - портируйте и будет вам Щастье :)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	48. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Sergey722 (ok) on 13-Май-15, 09:02
	Зачем, если есть aptitude?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	9. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	–2 +/–
	Сообщение от Аноним (??) on 12-Май-15, 04:04
	Я бы не стал доверять питону обновление системы. Это не рядовая административная задача. Но в данном случае на нем много раз наступали на грабли. Можно было бы его заменить. Но видимо ума хватает только на питон.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	10. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+2 +/–
	Сообщение от AsukaLangleyfag on 12-Май-15, 04:37
	Portage тоже на python, но не видно чтобы гентушники жаловались.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	13. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Аноним (??) on 12-Май-15, 06:13
	> Portage тоже на python, но не видно чтобы гентушники жаловались. А чего им жаловаться то? когда апдейт мира длиться в среднем 30 минут. Тут хоть на си напиши лучше не станет.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	53. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Аноним (??) on 14-Май-15, 01:54
	Я помню апдейт мира на Pentium I занимал у меня трое суток и после этого я сразу перешел  на Debian, но потом всетаки немного образумился и вернулся на CentOS.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	57. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от anonimous on 15-Май-15, 15:20
	На дебиан наговаривать? Это ты зря...
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	28. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+2 +/–
	Сообщение от redwolf (ok) on 12-Май-15, 15:22
	Честно говоря, наличие среди утилит работающих на питоне и перле осложняют жизнь гентушникам. Жалуемся.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	39. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от AsukaLangleyfag on 12-Май-15, 23:16
	Как решение разве что http://paludis.exherbo.org/index.html могу предложить.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	21. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+2 +/–
	Сообщение от Владимир (??) on 12-Май-15, 09:14
	питон не обновляет систему, если шо. Он говорит, какие пакеты нужно установить.  Обновляет rpm ;)
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	32. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+1 +/–
	Сообщение от Пингвино (ok) on 12-Май-15, 18:50
	Тсс, никому не говори, а то у школьников бомбить начнет
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	44. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Аноним (??) on 13-Май-15, 05:18
	Иди почитай еще раз как наставляться rpm'ки. Подсказка есть такая штука librpm.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	14. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+1 +/–
	Сообщение от Аноним (??) on 12-Май-15, 07:01
	> Python самое то -- для задач административных утилит! Ждем от тебя замену systemd на питоне.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	37. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Аноним (??) on 12-Май-15, 22:52
	>> Python самое то -- для задач административных утилит! > Ждем от тебя замену systemd на питоне. предлагаю назвать этот проект "SystemP" или "SystemPD" ;)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	18. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+3 +/–
	Сообщение от Michael Shigorin (ok) on 12-Май-15, 09:05
	> Python самое то -- для задач административных утилит! Есть старое детское проклятье -- "чтоб ты в туалет по компасу ходил"; почему-то вспомнилось...
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	23. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	–1 +/–
	Сообщение от anonymous (??) on 12-Май-15, 10:58
	Питон - самое то для реализации логики (для этой цели язык вполне ничего, плюс, согласен, нету гемора с компиляциями и пр), а команды вызывать на Баше всё же поудобней будет
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	36. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Аноним (??) on 12-Май-15, 22:51
	> Питон - самое то для реализации логики (для этой цели язык вполне > ничего, плюс, согласен, нету гемора с компиляциями и пр), а команды > вызывать на Баше всё же поудобней будет логика подсказывает что для реализации "логики" лучше ....Логические ЯП, то есть Пролог, Руби, Эрланг, соотф. идеально с элементами ФП, как в APL, D, Erlang и прочими ништяками жизненными :)
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	40. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	–2 +/–
	Сообщение от AlexAT (ok) on 12-Май-15, 23:36
	А лучше всего для системных элементов - что-нибудь с вменяемым синтаксисом, чтобы при необходимости влезть в исходники не разбираться, а где же там пробельчик лишний, или почему операнды в обратном порядке, или что делает вот энта вот херамбула из 10 спецсимволов подряд, которая ещё и не регэкс. Т.е. всё перечисленное выше (вместе с пистоном и перлом) практически отпадает. Шарпы с жабой отпадают из-за монструозности (а где там вот этот 100500-й класс в 999 модуле 666 уровня вложенности?). Остаются C, плюсы, баш (дань традиции), ну и скриптовые языки с C-подобным синтаксисом (из таковых только PHP на ум приходит, и с монструозностью рантайма у него, конечно, тоже не всё гладко, но по крайней мере баланс native code/script там соблюдается лучше). Да, в сях и прочих тоже есть свои сложности - но там хотя бы синтаксис человеческий. Лучше потратить время на собственно однократное изучение сложной логики, чем на регулярный разбор выдуманной для повышения ЧСВ тарабарской грамоты.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	49. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	–1 +/–
	Сообщение от anonymous (??) on 13-Май-15, 12:27
	теоретик? вот честно, написали сами что-нибудь в своей жизни сложнее "хэллоу ворда", особенно на перечисленных языках, или так, по набору фич посмотрели, что "лучше подходит" для данной задачи?
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	52. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от AlexAT (ok) on 13-Май-15, 19:54
	> теоретик? > вот честно, написали сами что-нибудь в своей жизни сложнее "хэллоу ворда", особенно > на перечисленных языках, или так, по набору фич посмотрели, что "лучше > подходит" для данной задачи? Я вполне себе пишу на нескольких из вышеперечисленных языков, и начинал вообще с ассемблера. Так что претензия мимо кассы. Или это не мне было? xD
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	26. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Аноним (??) on 12-Май-15, 12:47
	> Слушайте, а почему не напишут на C/C++ или на GO? Давно ведь > проситься, а то ведь питон же уходит в лету с каждой секундой. Если писать со встроенными драйверами распределённых рассчётов, происходящих на какойнить куде, да ещё квейк туда вставить в качестве нескучного интерфейса выбора устанавливаемых пакетов, сглаживающего время ожидания подсчёта зависимостей, и систему обмена данными с хабблом и загрузку на systemd, тогда -- да, нужен C/C++.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	45. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+1 +/–
	Сообщение от Аноним (??) on 13-Май-15, 05:22
	>> Слушайте, а почему не напишут на C/C++ или на GO? Давно ведь >> проситься, а то ведь питон же уходит в лету с каждой секундой. > Если писать со встроенными драйверами распределённых рассчётов, происходящих на какойнить > куде, да ещё квейк туда вставить в качестве нескучного интерфейса выбора > устанавливаемых пакетов, сглаживающего время ожидания подсчёта зависимостей, и систему > обмена данными с хабблом и загрузку на systemd, тогда -- да, > нужен C/C++. Для того что бы послать питоно-фанбоя нужны всего 8 букв. *** ** ***
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

4. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
Сообщение от Аноним (??) on 12-Май-15, 01:36
>> созданной в рамках проекта openSUSE Лучше бы обе системы использовали zypper, но нет, каждый пишет свой велосипед!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	–1 +/–
	Сообщение от AsukaLangleyfag on 12-Май-15, 05:37
	А ответ находится очень близко: https://fedoraproject.org/wiki/Features/DNF#Why_not_zif.2Fzy...
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	12. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Аноним (??) on 12-Май-15, 06:11
	Детские отмазки для прикрытия NIH синдрома.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	19. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Michael Shigorin (ok) on 12-Май-15, 09:08
	> Детские отмазки для прикрытия NIH синдрома. Не совсем так.  С одной стороны, шляпа хочет контролировать _всё_, что поставляет (upstart они уже покушали).  С другой -- "в качестве основных проблем Yum, которые побудили к созданию DNF" не упоминают главную: трагическую смерть разработчика yum, повлёкшую невозможность его поддержки имеющимися силами.  Тот самый bus factor в единицу.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	38. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	–1 +/–
	Сообщение от crypt (ok) on 12-Май-15, 22:57
	я не так давно с удивлением заметил, что rpm линкуется с lua... я не знаю, можно ли было развивать yum дальше, но все это выглядит что-то без единого дизайна и со всех сторон подкостыленное разными lua, python ... и до кучи каким-то "хакки" (hawkey - наконец все хаки объединили в библиотеку).
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	42. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	–1 +/–
	Сообщение от Анончег on 13-Май-15, 00:14
	> я не так давно с удивлением заметил, что rpm линкуется с lua... > я не знаю, можно ли было развивать yum дальше, но все > это выглядит что-то без единого дизайна и со всех сторон подкостыленное > разными lua, python ... и до кучи каким-то "хакки" (hawkey - > наконец все хаки объединили в библиотеку). Так! Плюсанул.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

8. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
Сообщение от Аноним (??) on 12-Май-15, 04:00
>> прекращение поддержки опции "--skip-broken" это они "хорошо" придумали:) А в замен то что?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от SunXE (ok) on 12-Май-15, 11:04
	Эта опция теперь там по умолчанию включена.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	50. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Аноним (??) on 13-Май-15, 16:46
	Это они еще лучше придумали.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	51. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Andrey Mitrofanov on 13-Май-15, 16:52
	> Это они еще лучше придумали. Фороникс тоже http://www.phoronix.com/scan.php?page=news_item&px=DNF-One-P... фшоке.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

16. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+2 +/–
Сообщение от Аноним (??) on 12-Май-15, 08:57
>API для плагинов и интеграции с другими приложениями, такими как инсталлятор Anaconda Оно еще живо? Кривейшее поделее, выжирающее память гигабайтами, с системными требованиями большими чем у самого дистрибутива.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Michael Shigorin (ok) on 12-Май-15, 09:09
	>> такими как инсталлятор Anaconda > Оно еще живо? Кривейшее поделие, выжирающее память гигабайтами Насколько помню, жручим шляпный инсталер стал после того, как его пересадили на урезанную гномосессию -- пока стартовали иксы и поверх них змеюка, так вроде ещё как-то держались...
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

22. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
Сообщение от Аноним (??) on 12-Май-15, 10:22
А зачем в fedor'е нужен dnf? Ведь теперь он, как и PackageKit - настройка над hawkey. Кому нужна консоль - есть pkcon.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	33. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Илья (??) on 12-Май-15, 20:21
	yum install nano Разве не локанично? Разве это не идеальная команда, которая самостоятельно, без показа рекламы и установки амиго-браузера поможет вам в быту?
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

25. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
Сообщение от Аноним (??) on 12-Май-15, 12:15
питон не модно, лучше бы новый язык придумали
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Аноним (??) on 12-Май-15, 13:39
	> питон не модно, лучше бы новый язык придумали Так это, того... http://ceylon-lang.org/
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	30. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Stax (ok) on 12-Май-15, 17:32
	А почему не http://www.rust-lang.org/ ??
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	31. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от CrazyAlex25 (ok) on 12-Май-15, 18:08
	Как много оказывается ЯП с доменом *-lang.org    (https://goo.gl/eVT3Jp)
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	34. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Аноним (??) on 12-Май-15, 21:26
	Есть еще без тире, например http://hacklang.org/
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	35. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	–1 +/–
	Сообщение от Аноним (??) on 12-Май-15, 22:50
	дистры с пакетным менеджером, елозящим на Perl, Ruby и даже PHP, Tcl, JS - были уже. даже с Lua было :) так что бидон - не так фигово. вот залудят для него JIT, жабо-стайл(а не как в фэйсбукес сделано, масштабируемо, но меееедленно) - будет прикольнее, хотя в целом, конечно - не труЪ подход и язык.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	41. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от AlexAT (ok) on 12-Май-15, 23:45
	> труЪ подход и язык. Да, вот только JIT'а для компонентов системы нам и не хватает для полного счастья. Чтобы как у MS - при каждом апдейте системного класса 100500 уровня зависимости 99% ресурсов проца на JIT на десять минут, а юзер подождёт.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	43. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+1 +/–
	Сообщение от й on 13-Май-15, 01:11
	да и с питоном были. мне месяц назад тут рассказывали, что emerge (python, gentoo) гораздо тормознее homebrew (ruby, mac) из-за неисчерпаемой функциональности. впрочем, yum и emerge -- птицы где-то одинаковой неторопливости. можно быстрее.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

46. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
Сообщение от Igor (??) on 13-Май-15, 08:26
На днях попользовался сим чудом в 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 без его очистки. Всякие их новые опции не помогли. Это всего только первая версия и ее конечно же расширят. Но на данный момент отличия все таки, как по мне, значительные. Отличия или баги? Удачи разработчикам.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	55. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+1 +/–
	Сообщение от Аноним (??) on 14-Май-15, 22:24
	В таких постах очень неплохо в конце смотрятся ссылки на баг-репорты.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	56. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Igor (??) on 15-Май-15, 13:16
	Вот, например, практически мой случай: 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&produc... Взгляд на один только этот список говорит, что проблем очень много. Желаю удачи разработчикам. Надеюсь, что DNF может и будет в будущем хорошей заменой Yum. Хотя последний меня устраивает.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	59. "Увидел свет пакетный менеджер DNF 1.0, пришедший на смену Yu..."	+/–
	Сообщение от Igor (??) on 29-Май-15, 08:50
	В релизе Fedora 22 'dnf download --resolve ...' вроде как починили. Пользуюсь три дня с момента установки и пока все в порядке с зависимостями. Для закачки пакетов только под конкретную архитектуру можно добавлять расширение (например: .х86_64) и/или маску (например: *). Например: dnf download --resolve mc.x86_64
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема