The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Началась разработка пакетного менеджера DNF 5 и замены PackageKit

06.03.2020 13:34

Дэниел Мах (Daniel Mach) из компании Red Hat сообщил о начале разработки пакетного менеджера DNF 5, в котором будет выполнен перенос реализованной на языке Python логики DNF в библиотеку libdnf, написанную на C++. Тестирование DNF 5 планируется начать в июне в процессе разработки Fedora 33, после чего в октябре 2020 года добавить в репозиторий Rawhide, а в феврале 2021 года заменить им DNF 4. Сопровождение ветки DNF 4 будет продолжено, так как она применяется в Red Hat Enterprise Linux 8.

Отмечается, что проект достиг состояния, в котором почти невозможно продолжать развитие кода без нарушения совместимости на уровне API/ABI. Главным образом это связано с потерей актуальности PackageKit и невозможностью развития libdnf без изменения API "libhif". При этом, несмотря на намерение поменять API, в качестве основных приоритетов называется сохранение обратной совместимости на уровне интерфейса командной строки и API.

Поддержка Python API в DNF будет оставлена, но написанная на Python бизнес-логика будет перенесена в библиотеку libdnf (C++), что позволит гарантировать идентичность работы пакетного менеджера в дистрибутиве. Разработка будет сосредоточена вокруг C++ API, а Python API будет автоматически генерироваться в форме обвязки на его основе. Аналогичным образом будут сформированы биндинги для Go, Perl и Ruby. После стабилизации C++ API на его основе будет подготовлен и C API, на который будет переведён rpm-ostree. Hawkey Python API будет удалён и заменён на libdnf Python API.

Основная функциональность DNF будет сохранена. Благодаря наличию большого тестового набора (около 1400 тестов) ожидается, что переработка API не скажется на интерфейсе командной строки для конечных пользователей. Возможно немного изменится разбор аргументов и вывод, но эти изменения будут хорошо документированы. В урезанной версии microdnf, применяемой в контейнерах, планируется реализовать подмножество возможностей DNF, достижение полного паритета в функциональности не рассматривается.

Вместо PackageKit будет создан новый сервис DBus, предоставляющий интерфейс для управления пакетами и обновлениями для графических приложений. Данный сервис планируется разработать с нуля, поэтому его создание может потребовать много времени. PackageKit последнее время не развивается и находится в режиме сопровождения с 2014 года из-за потери актуальности. С продвижением систем Snaps и Flatpak дистрибутивы теряют интерес к PackageKit, например, он уже не поставляется в сборках Fedora SilverBlue. Уровень абстракции для управления пакетами во многом обеспечивается штатными центрами управления приложениями GNOME и KDE, которые позволяют устанавливать flatpak-пакеты на уровне отдельных пользователей. Унифицированный системный API для получения списка установленных пакетов становится не настолько полезен как раньше.

  1. Главная ссылка к новости (https://lists.fedoraproject.or...)
  2. OpenNews: В DNF предлагают встроить UUID для идентификации установок Fedora
  3. OpenNews: План по замене пакетного менеджера Yum на DNF в Fedora 22
  4. OpenNews: Доступен пакетный менеджер DNF 2.0, пришедший на смену Yum
  5. OpenNews: Пакетный менеджер DNF будет переработан на языке Си
  6. OpenNews: Выпуск PackageKit 1.0.0. Планы по развитию универсального установщика пакетов
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/52494-dnf
Ключевые слова: dnf, yum, rpm, fedora
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (109) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 13:39, 06/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +46 +/
    Испытываешь странное чувство, когда даже и не переходил на PackageKit, а его уже закапывают и пишут новое. Прям как в вёбе.
     
     
  • 2.2, Аноним (2), 13:55, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Так те же люди пишут.
     
     
  • 3.73, Аноним (73), 02:38, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Автор yum вроде угодил на велосипеде под автотранспорт.
     
     
  • 4.109, Аноним (109), 10:07, 10/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    2013 год, как то давно уже.
     
  • 3.87, Аноним (-), 05:02, 08/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Алилуя, через цать лет доползло что картонный макет пакетного менеджера - не рулит. После того как даже фрибзда сделала какое-то подобие нормального этсамого... А у этих - бизнеслогика, клять, в пакетном менеджере.
     
  • 2.4, Аноним (-), 14:00, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Испытываешь странное чувство, когда даже и не переходил на PackageKit, а его
    > уже закапывают и пишут новое.

    Еще страннее - месяц назад некоторые местные слюной брызгали, доказывая очередное превосходство пингвинчика
    > Благодаря packagekit, гномовские/кдешные/whatever инструменты работы с софтом (установка, обновление) одинаково работают на всех мейнстримовых дистрах.

    а тут вон оказывается что то ли его уже много лет никто не развивает, то ли у шапки дистры маргинальные :-S

     
     
  • 3.9, Аноним (9), 14:25, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> уже закапывают и пишут новое.
    >Еще страннее - месяц назад некоторые местные слюной брызгали, доказывая очередное превосходство пингвинчика

    Летели 2 кирпича, один красный, а другой - налево...

     
     
  • 4.101, Аноним (101), 15:35, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, как бы, проект, который допиливают, не может претендовать на превосходство.
    Превосходно лишь то, что не трогают десятилетиями, ведь отсутствие необходимости в изменениях означает полное совершенство! (Нет, оно не может быть обусловлено тем, что на проект все просто забили, скажете тоже.)
    [/sarcasm]
     
     
  • 5.106, Аноним (-), 00:48, 10/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если софт перестают допиливать и он сложнее хелловорлда - этот софт, очевидно, сдох.
     
  • 3.21, Аноним (21), 15:22, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    PackageKit - это один из инфраструктурных проектов редхата Он не для пользовате... большой текст свёрнут, показать
     
     
  • 4.69, GentooBoy (ok), 00:36, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Мы уже поняли что вас красношапка покусала, но зачем всем об этом рассказывать?
    То что шапка пилит что бы диктовать всем стандарты какие она хочет вам видимо не очевидно.
    Потому что если она может диктовать всем, то менеджер может приходить к потенциальному заказчику и бить в грудь что мы самые передовые и денежки нести нужно нам.
     
     
  • 5.93, RedhatBoy (?), 12:14, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    При чем тут покусала Пока что я вижу по нику что вас Gentoo покусала Покажите ... большой текст свёрнут, показать
     
     
  • 6.111, anononim (?), 14:48, 10/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну если уж systemG стандарт, то openrc, upstart, SystemV-init Их много, вы не вк... большой текст свёрнут, показать
     
     
  • 7.112, Аноним (21), 17:56, 10/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это не стандарты и API, а системы инициализации с сервисной моделью разной степе... большой текст свёрнут, показать
     
  • 4.84, Аноним (84), 18:25, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Такие проекты никто кроме красношапки не развивает никогда, потому что среднестатистический дистрибутив линукса не способен на бОльшую инновацию чем нескучные обои.

    Поправил, не благодари.

     
  • 4.100, Аноним (101), 15:32, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Такие проекты никто кроме красношапки не развивает никогда, потому что среднестатистический дистрибутив линукса не способен на бОльшую инновацию чем система инициализации и собственный пакетный менеджер и то не все. Причина банальна - ресурсов нет. Вместо разработки инфраструктурных решений для ОС разработчики в основном пакуют пакеты и обслуживают совместимость и надёжность программного обеспечения. Спасибо им за это, безусловно, это важно, но не хватает единых API.

    Окститесь, вы пытаетесь донести это до фaнбоя BSD!
    У них неприятие единых кросс-системных стандартов чуть ли не биологическое.

     
  • 3.52, коржик (?), 21:35, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а в чем проблема? превосходства пингвинчика никуда не делись
     
  • 3.72, колба (?), 01:25, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ну вот так получилось что они теперь одинаково работают на любом дистрибутиве и без ппакажкита..
     
  • 2.38, Аноним (38), 17:29, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Прям как в вёбе

    Троцкисты. Зато все заняты и не ленинизмят )

     

  • 1.3, DerRoteBaron (ok), 13:59, 06/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Подход, конечно, своеобразный, но yum/dnf+rpm самая адекватная связка для бинарного дистрибутива, а а с dnf еще и не особо тормозящая, так что от переписывания на плюсы есть шансы, что хуже не станет
     
     
  • 2.10, leap42 (ok), 14:46, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > yum/dnf+rpm самая адекватная связка для бинарного дистрибутива

    это ещё почему? zypper пользовались? (лучшие части dnf как раз из него взяты)

     
     
  • 3.33, йо ж (?), 16:33, 06/03/2020 Скрыто модератором
  • –3 +/
     
  • 3.56, DerRoteBaron (ok), 23:13, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > лучшие части dnf как раз из него взяты

    А не лучших, но тем не менее полезных там не хватает. Например, банальное действие по выкачиванию  пакетов (в т.ч. src.rpm) превращается в пляску с весьма странными второстепенными флагами, правами рута и доставанием загруженного из /var/cache. И другие вроде мелкие, но тем не менее бросающиеся в глаза при долгом использовании косяки.

    По мне он довольно неплох, но CLI у dnf куда логичнее, удобнее и полнее

     
  • 2.12, Аноним (12), 14:49, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Чем это лучше pacman?
     
     
  • 3.20, А (??), 15:17, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Чем это лучше guix?
     
     
  • 4.24, iFRAME (ok), 15:30, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Чем это лучше guix?

    Чем это лучше MSI?


     
     
  • 5.32, фу_быть_таким (?), 16:26, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Чем это лучше MSI?

    ERROR: your package is not supported. Please use the correct package format!

     
  • 5.95, Gogi (??), 13:16, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Что MSI - это дичайший гибрид СУБД и "логики инсталляторов". Всемогутер, который проще выкинуть, чем понять.

    Инсталлятор - это unzip + пара манипуляций с системой. Всё остальное - понты.

     
  • 4.49, Аноним (49), 19:39, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну гуикс, все же, немного о другом. Там же совсем "принципиально новый" способ организации пакетов
     
  • 2.30, evkogan (?), 16:05, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    попробуйте zypper и не надо будет изобретать велосипед dnf.
    Я еще понимал использование yum, который брал начало примерно из тех же лет, но был свой.
    Но вот вместо перехода на лучшее решение начать пилить очередное свое, а потом его перепиливать.
    У RHEL последнее время подход использовать только свои решения не глядя вокруг. Еще и навязывая эти решения остальным. Но это не значит что решения лучшие.
     
     
  • 3.39, IRASoldier_registered (ok), 17:33, 06/03/2020 Скрыто модератором
  • –1 +/
     
  • 3.45, Аноним (45), 17:58, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    DNF работает на том же движке, что и Zypper, и под капотом у обоих RPM. В качестве фронтэнда мне больше нравится Zypper – он удобнее, у него приятнее синтаксис и больше фич (но есть несколько мелких багов), но его почему-то не взяли. Всегда интересовал вопрос "почему?", и только что возникла догадка – как раз для того, чтобы переход yum -> dnf осуществлялся почти без изменений (команды, ключи), т.е. можно было сделать yum алиасом dnf'а.
     
     
  • 4.46, Annoynymous (ok), 18:07, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > DNF работает на том же движке, что и Zypper, и под капотом у обоих RPM.

    Это самый прекрасный бред, который я читал в 2020-м, спасибо!

     
     
  • 5.104, Аноним (104), 23:25, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    libsolv не тот же?
     
     
  • 6.107, Annoynymous (ok), 01:22, 10/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > libsolv не тот же?

    Не знаю, я отвечал про «под капотом у них rpm».

     
  • 3.60, DerRoteBaron (ok), 23:26, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    dnf лучше zypper примерно в тех местах, что и yum лучше zypper: более удобный, логичный и дееспособный CLI
     
     
  • 4.88, Аноним (-), 05:05, 08/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > dnf лучше zypper примерно в тех местах, что и yum лучше zypper:
    > более удобный, логичный и дееспособный CLI

    Особенно дееспособно он реагирует на аут памяти в процессе апдейта пакета, так что потом кишки не соберешь. О том чтобы дееспособный крап себя починил или хотя-бы подсказал how to - речь, разумеется, не идет.

     
  • 3.108, Annoynymous (ok), 01:24, 10/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > попробуйте zypper и не надо будет изобретать велосипед dnf.

    А zypper может выгрузить лог транзакций и проиграть их на другом сервере? А показать историю изменений по пакету?


     

  • 1.5, анонимус (??), 14:05, 06/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –11 +/
    > C++

    Странный выбор.

     
     
  • 2.8, DerRoteBaron (ok), 14:19, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • –15 +/
    У них половина кода уже на C++, видимо, разгонять или переучивать команду на более адекватный нативный язык, а потом еще и весь код переписывать, слишком невыгодно
     
     
  • 3.13, Аноним (12), 14:50, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > переучивать команду на более адекватный нативный язык

    Это на какой? Хруст, может?

     
     
  • 4.18, заминированный тапок (ok), 15:06, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    да уж сразу на JS :-D
     
     
  • 5.22, Аноним (21), 15:23, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    JS... вообще-то уже есть polkit
     
  • 2.16, заминированный тапок (ok), 15:01, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну там же нет любителей смузи, пока ещё
     
     
  • 3.35, Lex (??), 17:02, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну так на православном Си и писали бы..
     
  • 2.96, Gogi (??), 13:17, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    +1. Шёл 2020-ый год, мыши продолжали шаблонить бабушку, несмотря на то, что прямо перед носом развивается Ди.
     

  • 1.6, Джонни Дырявый (?), 14:17, 06/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    DNF будет такой же тормозной как в Федоре?
     
     
  • 2.37, BlackRot (ok), 17:09, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В каком месте он тормозит?
     
     
  • 3.89, Аноним (-), 05:09, 08/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > В каком месте он тормозит?

    В операционке. Достаточно посмотреть разок на какой-нить apt... :)

     
  • 2.43, Аноним (45), 17:53, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.opennet.ru/opennews/art.shtml?num=52494#40
    #40 и #41
     
     
  • 3.74, Аноним (73), 02:41, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    python не тормозит (R)
     
  • 2.53, коржик (?), 21:41, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    пользуюсь dnf на домашнем ноуте, проблем не замечал. вы когда-нибудь накатывали сервис пак на десяточку или мак?
     
     
  • 3.85, Аноним (84), 18:28, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и где ты в десятке сервиспаки видел?
     
     
  • 4.113, коржик (?), 21:59, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну и где ты в десятке сервиспаки видел?

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

    Забавно, что если у вас ноутбук, то он всю подковёрную деятельность десятки выдаёт шумом вентилятора.

    Вот блокирую я экран, отхожу на 5 минут, а ноут начинает гудеть как ошпаренный. Это проснулась мафия

     

  • 1.7, Аноним (7), 14:18, 06/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    > перенос реализованной на языке Python логики DNF в библиотеку libdnf, написанную на C++

    Судьба-судьбинушка всех проектов, написанных на пихоне.

     
     
  • 2.11, leap42 (ok), 14:48, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Судьба-судьбинушка всех проектов, написанных на пихоне
    > ... всех проектов ...
    > ... всех ...

    ну как всех, 0,05% от всех может быть...

     
     
  • 3.15, A.Stahl (ok), 14:57, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Ок, всех полезных проектов.
     
     
  • 4.27, пох. (?), 15:50, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    как, обоих?!

     
  • 2.23, Аноним (23), 15:27, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Полютос Что-то не особо спасло переписывание на плюсы. Он даже не стал быстрее работать. В чём смысл переписывания?
     
     
  • 3.28, redgad (?), 15:51, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    No python dependency.

    (задолбались мы менять по всем скриптам /usr/bin/python на /usr/bin/python3, а эти ненормальные того гляди - предложат менять на python4.2.1.0.0.22 в следующей версии)

     
     
  • 4.34, Аноним (23), 16:40, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну это говорит только о качестве скриптов и их авторов. Самая боль для меня была поддерживать 2 на венде (не cygwin, msvc пакет с компилятором для питона только у 2 был) и 3 на линуксе, в 1 кодовой базе. Мне кажется это проблема дистрибутива, просто дефолтный уже давно должен быть 3.
     
     
  • 5.57, пох. (?), 23:17, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    а причем тут качество скриптов Разработчики пихон заявили и выпустили какой... большой текст свёрнут, показать
     
     
  • 6.63, Аноним (23), 23:38, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Так они видимо научились на своих ошибках. 2 объективно надо было дропать сразу, продакшен бы подорвался и в темпе решил все проблемы. С python3 наверно подготавливают почву для python4, чтобы избавиться от всего этого крапа, через который пришлось проходить с 2 и 3. А что они сломали там в плане совместимости? Вроде же пишешь для 3.2, и работает "без изменений" в 2.6+ и любых версиях 3, нет? Пусть хуже и медленней, да и код выглядит не очень, но работает же. Если пишешь для 3, просто берёшь версию старше той, для которой написано. В 4 собирались сломать совместимость, я надеюсь им хватит ума не повторить историю с 3. Но это ещё не скоро.
     
     
  • 7.65, пох. (?), 23:56, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вот редхат подорвался и решил проблему - нет пихона, нет проблемы.

    Полагаю, уважающий себя продакшн будет эти проблемы решать точно так же. А останется только наколенное одноразовое творчество васянов, ну и то, у чего уже просто не хватит ресурсов на переписывание на чем-то адекватном.

    > Вроде же пишешь для 3.2, и работает "без изменений" в 2.6+ и любых версиях 3, нет?

    нет. После 3.5 уже много чего не работает.
    Некоторые подробности излагали авторы hg. b'string' vs 'string' особенно им доставила.

    Надысь вон выяснилось, что пихон отменил 'None' - теперь нельзя его использовать в сортируемых списках.

     
     
  • 8.66, Аноним (23), 00:17, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нужность hg ещё под большим вопросом Какие ещё string Они ламеры, не иначе ... текст свёрнут, показать
     
  • 8.90, Аноним (90), 06:21, 08/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да там каждый минорный D релиз ведет к эпопее Так что единственное для чего он... текст свёрнут, показать
     

  • 1.17, Fracta1L (ok), 15:02, 06/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Нет, всё-таки это нифига не нормально, когда делают А, через 5 лет А выкидывают и пилят В, чтобы ещё через 3 года выкинуть В в пользу С.
     
     
  • 2.19, vz_2 (?), 15:11, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Работать на ведро вполне нормально для opensource.
     
  • 2.97, Gogi (??), 13:19, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так всё зависит от архитектора! Влезает в FOSS какой-то прыщедрот, вчера освоивший пестон по трём веб страничкам и поехали кошмакодить! Хотя казалось бы, таких на пушечный выстрел нельзя подпускать даже для "улучшения" софта. Отсюда и позорное качество большинства поделий.
     

  • 1.25, Аноним (25), 15:30, 06/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Серьезно? На 7 год индеец Быстрый Как Ветер заметил, что тормознее dnf только портаж, который компилирует пакеты и неплохо бы переписать этот кусок говна на нормальном языке? Невероятная скорость реакции! Энтерпрайз!
     
     
  • 2.40, Аноним (45), 17:49, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    DNF уже давно стал быстрым:

    https://www.opennet.ru/opennews/art.shtml?num=47471

    > 30.10.2017 20:35
    > По сравнению с YUM 3 в YUM 4 наблюдается существенный прирост производительности, особенно при

    разрешении зависимостей

    И это реально стало заметно. Говорю как тот кто был вынужден пользоваться на работе федорой с 20 по 28.

    На путаницу имени yum/dnf можно не обращать внимания, Red Hat меняет его туда-сюда.

     
     
  • 3.41, Аноним (45), 17:52, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если не понятно: да, он жутко тормозил. А потом с очередным апгрейдом дистрибутива вдруг стал заметно живее даже на HDD. Самая медленная часть – обновление инфы о пакетах с репозиториев. Разрешение зависимостей в повседневных задачах почти моментальное, установка ничем не медленнее Zypper или APT.
     
     
  • 4.82, anonymous (??), 14:56, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мне кажется очень странным, что я прошу установить пакет, а он "обновляет инфу о пакетах с репозиториев". Я его просил? Я очень ценю свою время, и не люблю когда его так бесполезно растрачивают.
     
     
  • 5.105, Аноним (104), 23:27, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    К сожалению, zypper грешит тем же, более того – даже если он не обновляет информацию о пакетах, он всё равно связывается с репозиториями по неясной причине. У pacman, apt, portage и многих других ПМ такой херни нет.
     
  • 5.110, КО (?), 11:15, 10/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Мне кажется очень странным, что я прошу установить пакет, а он "обновляет инфу о пакетах с репозиториев".

    Если Вы просите установить локальный пакет, без сторонних зависимостей, то он этого и не делает. А в противном случае ему надо узнать откуда брать пакеты. И это нормально. А периодичность опроса - дело настраиваемое.

    P.S. Другое дело скажем Мавен. Сначала выкачяать метадату с репозиториев. Потом разложить ее по кучи мест. А затем начать выкачивать все пакеты из всех серверов. После чего свалиться по фатальной ошибке, что "связи с левым сервером нет, но версия пакета уже есть в кеше Мавена". Вот это я понимаю подход к пакетному менеджеру. :(

     
  • 3.81, anonymous (??), 14:54, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да вот я вынужденно сейчас пользуюсь yum/dnf после привычного apt. И каждый раз, когда пользуюсь пакетным менеджером, офигиваю насколько всё медленно (всё никак не привыкну). Ну и неудобно, конечно же, но это уже субъективно.
     
  • 2.86, Аноним (84), 18:31, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >тормознее dnf только портаж, который компилирует пакеты

    Зато у нас в процессе буковки с циферками красивше по экрану бегают. И ЧСВ растёт на порядки. Шестнадцатеричные.

     

  • 1.26, Аноним (26), 15:33, 06/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    C++ будет одинаково работать на всех платформах? Теперь оно ещё и к железу привязано будет?
     
     
  • 2.29, redgad (?), 15:55, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    kokokokoй ужос! Вы еще сейчас и обос.етесь, когда узнаете что у вас ядро линукса - вообще на си написано - оно еще и к железу привязано, представляете?!


     

  • 1.31, user90 (?), 16:14, 06/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "из компании Red Hat" - и аж скулы сводит! Вспоминаешь ту же OpenSUSE: чем она была раньше, и чем она стала теперь.
     
     
  • 2.58, пох. (?), 23:20, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Труп смердящий еси.

    Да и была им же. Уже много-много лет.

     

  • 1.36, Аноним (45), 17:06, 06/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    «Мы решили заменить старый велосипед новым более современным велосипедом»
     
  • 1.42, псевдонимус (?), 17:53, 06/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    И здесь уродский дбус.


    Что еще упоротый бот считает ненлрмативной лексткой. В этот раз это сдово бастардский, в русском переводе.

     
     
  • 2.59, пох. (?), 23:20, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не уродский, а редхэтовский.
    "наша корова, и мы ее доим".

     
  • 2.80, Нонон (?), 12:11, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А тут DBus или DBus Broker?
     

  • 1.44, Аноним (44), 17:57, 06/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Странные там ребята сидят. Пишется за час с лишнем на Golang.
    А тут годами что-то разарбатывают на Python и C++.
    Короче странные ребята.
     
     
  • 2.47, leap42 (ok), 18:55, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Странные там ребята сидят. Пишется за час с лишнем на Golang.
    > А тут годами что-то разарбатывают на Python и C++.

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

     
     
  • 3.75, Аноним (73), 02:41, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Звучит на правду
     
  • 3.76, Козульщик из RedHat (?), 02:42, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ДА!
     
  • 2.83, Аноним (83), 17:47, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    у голанга версии максимум два года поддерживаются, нет  LTS веток
     

  • 1.48, Ilya Indigo (ok), 19:36, 06/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > ...в котором будет выполнен перенос реализованной на языке Python логики DNF в библиотеку libdnf, написанную на C++.

    С этого и нужно было начинать!
    Тогда бы и переносить не нужно было.

     
  • 1.50, mikhailnov (ok), 19:52, 06/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Надеюсь, продвигатели flatpak обломаются в своих попытках навязать свои контейнеры всем, а графические "магазины приложений" продолжат уметь ставить нормальные пакеты через packagekit.
     
     
  • 2.51, user90 (?), 20:09, 06/03/2020 Скрыто модератором
  • –2 +/
     
     
  • 3.54, анонимуслинус (?), 22:01, 06/03/2020 Скрыто модератором
  • +/
     
     
  • 4.55, Аноним (23), 22:33, 06/03/2020 Скрыто модератором
  • +/
     
  • 3.68, mikhailnov (ok), 00:21, 07/03/2020 Скрыто модератором
  • +/
     
  • 2.61, пох. (?), 23:30, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    не, не обломаются.

    Эпоха _совсем_ дерьмовых программ, неспособных работать в сантиметре от той помойки, за которой сидел их разработчик - давно настала.
    Единственный способ сделать их хоть полу-работающими - очень тщательно завернуть в дерьмоконтейнер вместе со всем мусором, валяющимся вокруг.

    Попутно это же решает проблему обмазывания свежайшим, так любимого что дЭффективными менеджерами, что обезьянками. Поскольку затолкать новую версию программы в дистрибутив - весьма вероятно означает поапгрейдить его половину (потому что нужны еще недописанные версии библиотек, а с ними, в свою очередь, несовместимы прочие программы, и их тоже надо менять на новейщие еще дымятся)

    Поэтому остается только другой вариант - затолкать весь дистрибутив в программу.

    Новый стандарт же ж, жрите, не обляпайтесь.

     
     
  • 3.62, анонимуслинус (?), 23:36, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    честно говоря все это ничем не отличается от статической линковки обмазаной новым слоем)) история по спирали?
     
     
  • 4.64, пох. (?), 23:40, 06/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    отличается. Не говоря уже о том что статическая сборка в gcc поломана двадцать лет как.

    Это копия (частей) _системы_, а не только конкретные версии динамических библиотек.
    Внутри, внезапно, могут быть не только бинарники, но и какая-нибудь js-пакость.

    Причем вперемешку.

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

     
     
  • 5.70, анонимуслинус (?), 00:49, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ну как факт переизобретают тоже. в свое время от статики стали уходить именно по причине уменьшения размера окончательного пакета и меньшему потреблению оперативной памяти при использовании разделяемых библиотек. так они опять за свое , только в еще более худшем варианте. так они линукс в винду помоечную превратят в 2 счета.  
     
  • 3.67, mikhailnov (ok), 00:20, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Эпоха _совсем_ дерьмовых программ, неспособных работать в сантиметре от той помойки, за которой сидел их разработчик - давно настала.

    В энтерпрайзе, может, и настала, в опенсорсе пока нет таких проблем в больших масштабах. И не будет, пока жива распространена традиционная система нормального опакечивания.

     
     
  • 4.71, анонимуслинус (?), 00:54, 07/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    это пока она есть. пока писателям всяким не станет удобно не париться сборкой под конкретную платформу, а выложить готовый пакет без исходников. кстати сменив при этом лицензию. или корпорациям заворачивать свои дрова с зондами вообще без возможности просмотра исходников. и получаем вуаля винукс в перспективе. а ведь все больше народа тащет проги в во всех этих контейнерных форматах.
     
  • 2.92, Аноним (92), 12:07, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Надеюсь, продвигатели flatpak обломаются в своих попытках навязать свои контейнеры всем

    Если не можешь обеспечить поддержку Flatpack в ROSA, пожелай донору смерти.

     
     
  • 3.98, mikhailnov (ok), 13:33, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> Надеюсь, продвигатели flatpak обломаются в своих попытках навязать свои контейнеры всем
    > Если не можешь обеспечить поддержку Flatpack в ROSA, пожелай донору смерти.

    Не переживай, будет в ней flatpak и GUI для него, а вот где ты увидел "пожелания смерти", интересно.

     
     
  • 4.99, Аноним (92), 14:11, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Надеюсь, продвигатели flatpak обломаются
    > Не переживай, будет в ней flatpak

    Ты теперь сам продвигатель flatpak. Пусть сбудутся твои надежды.

     
     
  • 5.102, mikhailnov (ok), 16:14, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >>>> Надеюсь, продвигатели flatpak обломаются
    >> Не переживай, будет в ней flatpak
    > Ты теперь сам продвигатель flatpak. Пусть сбудутся твои надежды.

    Я лишь пытаюсь дать пользователям возможность пользоваться flatpak, если они хотят его или он им нужен. Да, это немного его продвигает. Но не навязывает. И в отличие от сабжа я не пытаюсь вынудить кого-то отказаться от традиционных пакетов в пользу контейнеров.

     
     
  • 6.103, Аноним (92), 16:16, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > а нас то за шо?

    за то.

     

  • 1.78, Аноним (78), 11:12, 07/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Hawkey Python API будет удалён и заменён на libdnf Python API.

    Сначала удалят, а потом через 10 месяцев добавят?

     
     
  • 2.91, Аноним (-), 01:59, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Сначала удалят, а потом через 10 месяцев добавят?

    Я бы на их месте вообще питон дропнул из системы. Это столько человекочасов бы всему глобусу сэкономило...

     

  • 1.94, Аноним (94), 12:33, 09/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    dnf настолько тормоз, что даже представить себе не мог
    был опыт с apt, pacman, xbps, может разница по скорости где и была, но внимание на то не обращал - работать нигде это не мешало
    то ли дело dnf, запускаешь банальную команду а-ля search и сразу переключаешься на какие-то другие дела, дожидаться исполнения у меня лично терпения не хватает, особенно при первом запуске, когда сначала оно просто тупит, потом неторопливо посинхронизируется с серверами, потом опять потупит, ну его, в общем
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру