Fedora, размер базы обновлений

Тоже считаю что это бред собачий. Особенно весело, когда после sudo dnf update ищешь какой-нибудь пакет dnf search (без sudo) - и он еще одну копию базы скачивает, обычному юзеру, в основной-то, конечно никак не глянуть.

Еще вроде эта хрень по дефолту автоматом грузится несколько раз в день.

В yum так же.

То же нахожу странным, как сделано в yum и dnf скачичивание базы и кеширование. Я не измерял размер, но оно задрало качать базу целиком.

И замуту с разной базой под разных юзеров (например, sudo и просто) так же я не оценил, анонимус выше правильно заметил.

Но, в общем, привык на этом не зацикливаться - хоть статус отображается, а не просто висит

Т.е. я думаю он качает полностью всю базу

Я честно говоря не совсем понял о чём спич. У меня upgrade пакетов происходит довольно шустро, если не много обновлений. Хотя подключено много репозиториев и часть наверно надо выкинуть. Можно дополнительно ключи использовать. И так на всякий случай. http://dnf.readthedocs.io/en/latest/command_ref.h.tml

У меня upgrade пакетов происходит довольно шустро

Ну ты же понимаешь, что это не техническое определение. У тебя канал 100 мегабит, а у меня 8, а у кого-то может трафик считается, а кто-то из антарктиды обновляется. Я говорю о цифрах: каждый раз при обновлении dnf update он качает 22 Мб. Разумеется, если есть обновления. Это полностью база репозитория Fedora 25 Updates. А должен качать несколько сотен Килобайт максимум — т.е. разницу между базой которая уже скачана и новой. Как во всех нормальных пакетных менеджерах.

Самое смешное, что оно еще часть пакетов обновляет через диффы drpm, т.е. как бы экономят трафик, при этом так лажают на обновлении реп.

Отключи автообновление в dnf.

Извиняюсь, но до меня туго доходит сегодня. Рабочая неделя длинная. Я так понимаю что 22 метра это список пакетов хранилища? Ясный перец он его будет качать и сравнивать с тем что уже установлено. Репозиторий не имеет информации о том что у тебя уже стоит и что тебе нужно. Используй только особо нужные репозитории. Сократится список. Я сейчас на работе и не под линкус, а то бы скинул скрипт как у меня делается какие ключи upgrade. В DNF Command Reference уже нет команды update хотя она и выполняется, пока.

Это вообще нормально?

Для RH вполне нормально.

Для RH вполне нормально.

Ты так говоришь, будто знаешь, как реализовать передачу по http или ftp разницы между двумя файлами, один из которых находится с одной стороны, а другой — с другой.

Как это делают в других дистрах?

Уже давно было сравнение apt и yum. У всех свои заморочки. Apt- быстрее.Yum - проще и умнее. Попробуй apt-rpm. В fedora он присутствует.

Как это делают в других дистрах?

ХЗ и не уверен, что в других дистрах делают именно так. Что же до dnf касательно, то он «тянет» базу либо если размер/дата изменения «там» отличны от локальной, либо по истечении 48 часов (значение по умолчанию для metadata_expire, см. dnf.conf(5)). К слову, можно попробовать сказать в dnf.conf check_config_file_age = 0.

i_gnatenko_brain, сколь я помню, ты dnf'ом занимаешься. Если так, не сочти за труд сказать что-нибудь умное по теме.

apt-rpm.
В fedora он присутствует.

8-0 Где? dnf search находит только fedora-package-config-apt.noarch.

Вы, наверно, разработчик yum/dnf? (на самом деле, скорее всего нет :))

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

Давно не имел дело с dnf, удивлен, что там до сих пор так, как на yum.

fedora-package-config-apt.noarch

Вот его и попробуй

Debian's Advanced Packaging Tool with RPM support Fedora 25 for

и базы метаданных (это не работает, о чем и тред)

Что за бред. Всё это работает. И при обновлении пишет даже сколько сэкономлено места за счёт установки дельты.

Debian's Advanced Packaging Tool with RPM support

Да, действительно, есть такое, dnf install apt для страждущих.

для страждущих.

Но думаю что это мало поможет. Потом упрёмся типа давайте rpm в dpkg всё перекинем.. В общем у всех разный подход к системе управления пакетами изначально, с самого 1999 года. Хотя RedHat мне больше по душе. Как старый бык сказал-«Мы пойдём медленно и ...»:-)

вот это тебе о чем нибудь говорит? https://imgur.com/HAXJFwo

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

22 МБ

Ну и что? Что мне дает список доступных пакетов? Я же, по этому списку, не всё качать буду. Вот что и как - это уже мной определяется. Кстати, dpkg

Не поддерживается технология Delta для экономии трафика

Это не я придумал а в интернете написано (хотя на заборах ещё не то увидишь:-)).

При чем тут dpkg? Вы явно с разработчиками dnf на одной волне.

Я же, по этому списку, не всё качать буду.

Однако, качать сам этот список ты будешь, все 22МБ, таков его размер, каждый раз. А хотелось бы дельту к нему.

А хотелось бы дельту к нему.

Я наверно совсем отупел на старости лет. Как ты эту дельту определишь не зная что у тебя стоит? Репозиторий для каждого клиента свой список данных держать должен?

Я, так понял, что ты отправляешь свой список в репозиторий и он определяет, что тебе нужно обновить? И это будет для всех желающих одновременно делать? Не жирно? А может я еще хочу не обновить а добавить?

Просто, что бы иллюстрировать, в знак солидарности с ТС. CentOS 7.

$ sudo yum update
Loaded plugins: fastestmirror, langpacks
base                                                                                                                 | 3.6 kB  00:00:00
elrepo                                                                                                               | 2.9 kB  00:00:00
epel/x86_64/metalink                                                                                                 | 6.6 kB  00:00:00
epel                                                                                                                 | 4.3 kB  00:00:00
extras                                                                                                               | 3.4 kB  00:00:00
google-chrome                                                                                                        |  951 B  00:00:00
nux-dextop                                                                                                           | 2.9 kB  00:00:00
updates                                                                                                              | 3.4 kB  00:00:00
(1/5): epel/x86_64/updateinfo                                                                                        | 786 kB  00:00:01
(2/5): extras/7/x86_64/primary_db                                                                                    | 151 kB  00:00:01
(3/5): updates/7/x86_64/primary_db                                                                                   | 4.8 MB  00:00:03
(4/5): elrepo/primary_db                                                                                             | 459 kB  00:00:06
(5/5): epel/x86_64/primary_db                                                                                        | 4.7 MB  00:06:29
google-chrome/primary                                                                                                | 2.0 kB  00:00:00

Тут, конечно, метаданные для updates не 22МБ, как в федоре. Но вот, например

(5/5): epel/x86_64/primary_db | 4.7 MB 00:06:29

при относительно небольшом размере, было выбрано странное медленное зеркало (это отдельный разговор, как работает fastmirror), и скачивание 4.7МБ продолжалось 6 минут. Хотя, несколько дней назад, yum update на этой же машине запускался, т.е. метаданные недельной давности на машине присутствуют, и дельта бы сыграла здесь отлично!

Видимо да.

У меня есть полная актуальная база метаданных на момент времени N1 = N. Она имеет идентификатор (пусть будет как в git, значние sha1) назовем его ID_N1. Во время N2=N+1 я вижу, что на сервере идентификатор изменился (ID_N2), и не совпадает с моим. Я прошу у сервера дельту данных между ID_N2 и ID_N1. Всё.

Информация об установленных у меня пакетах совсем не нужна.

Я прошу у сервера дельту данных между ID_N2 и ID_N1.

Но что бы спросить свою дельту ты разве не должен посмотреть список изменений? А если этот список обновляется полностью постоянно? Когда запускаешь yum extender он тебе показывает, красным цветом, только то что есть нового для тебя. Но он, перед этим, долго думает. И после этого upgrade происходит легко. На самом деле, то что ты описал, и происходит. Если сразу же ещё раз запустить yum extender - процесс моментальный и он ещё обматерит типа - не хрен тебе делать. Так что механизм там отлажен. Другой вопрос - размер списка.

Yum - проще и умнее

Ахаха, ты просто им не пользовался по-настоящему.

ты просто им не пользовался по-настоящему

Это как? По взрослому? Без трусов?:-)

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

Нет.

i_gnatenko_brain, сколь я помню, ты dnf'ом занимаешься. Если так, не сочти за труд сказать что-нибудь умное по теме.

Мне чё-т вспомнился его код на питоне…

Нет.

Вот он тебе и навалит... полный список. Ты приходишь в магазин со списком. Лазаешь сам по полкам и ищешь, что тебе нужно и посвежее. Продавец знает список товара и дату поступления. Ты, или сам сверяешься со списком и мучительно ищешь, теряя время, или ловишь продавца. Он быстро тебе всё найдет. Хорошо что в магазине народу нет. Ты один. А если народу много? Продавцов к каждому не поставишь.

Мне чё-т вспомнился его код на питоне...

А он тут причём? Это всё от бразильских обезmян исторически проростало.;-) Yup (производитель Yellow Dog) - yum -dnf.

Блин - ну сколько можно объяснять! В конфиге для каждого репозитория указано время хранения метаданных (например, для fedora-updates указано 6 часов). Именно столько будут действовать однажды-скаченные метаданные. Через 6 часов ты по новой скачаешь вся базу метаданных, даже если она не изменилась! А база большая и на медленном канале долго качается. И качается каждый раз целиком. А можно было-бы вполне сделать докачку недостающих у тебя метаданных, вместо тупого скачивания всей базы снова и снова каждый день.

При том, что он говнокодит по-чёрному в dnf.

Блин - ну сколько можно объяснять!

Вот и я говорю.... только по другому.

А можно было-бы вполне сделать докачку недостающих у тебя метаданных

Кто определит и как, что тебе родимому не хватает? Кроме тебя - никто этого не сделает. «Огласите весь список!...Пожалуйста» @Операция Ъ

Кто определит и как, что тебе родимому не хватает? Кроме тебя - никто этого не сделает

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

в dnf

here is another question:-)

В сусе вроде так же, но там есть оснавная репа, она не меняется, естл репа с апдейдами, там обновления частые, но пакетов там не так много, так что качает не много, ну и 100500 других реп, обновы которых жрут десятки кб. Ну а по теме тоже считаю очень глупо перекачивать по 20мб при обновлени одного пакета в репе.

Это элементарно - у меня уже есть вчерашняя версия базы. У нее есть идентификатор времени создания - да хоть дата-время в Unix time формате. Я отсылаю это время в своем запросе - и мне приходят только данные, новее указанного времени. Я дописываю эти данные к своим имеющимся и получаю полную базу на текущий момент. Фишка в том, что при регулярном запросе обновлений (а многие делают это каждый день) размер обновлений много меньше размера всей базы! Если же ты впервые скачиваешь обновления, то указав время = 0 получишь полную базу.

apt вполне определяет.

Там даже без обновлений перекачивается — просто когда база устаревает на клиенте.

Я с этим полностью согласен. И так , по логике, должно быть. Возникает куча проблем если у тебя подключены разные хранилища и в них, вполне может быть, пакеты с одинаковыми идентификаторами, но по сути чуть отличные.

Это уже совершенно другая проблема, как получив метаданные от разных репозиториев, свести их в одну общую базу. Она не имеет никакого отношения к методу скачивания метаданных из одного репо.

есть вчерашняя версия базы

Я по этому и давал ссылку на команды dnf. В любом случае, мы должны что то сказать системе, о том что мы от неё ждем. Там есть ключи. Вот сейчас не помню, что у меня в скриптах прописано и в настройках dnf.conf. Или --refresh (Установить метаданные как устаревшие перед запуском команды) или --best или что то еще замутил. Не помню. У меня обновления быстро проскакивают.Хоть и редко делаю(только ручками и только после backup;-))

угу, учитывая что на планете часовых поясов 24 штуки, не считая половинчатых, то реализация такого механизма выглядит несколько спецыфической.

Unix time.

«Все украдено до нас!» Для этого придумано UTC - универсальное координированное время. Подумай как работают с клиентами с разных часовых поясов SQL сервера, да даже в WWW-серверах активно используется пересчет времени в UTC (т.к. на многих сайтах используются временные метки в куках).

в «неэнтерпрайз-сурьёзный-бизнис-красношапка» мире уже изобрели хэши и release файлы. поэтому ламповый apt не творит такой неадекватной фигни. оказывается есть способы узнать, изменилось ли что-то с последнего апдейта

sudo dnf upgrade --refresh

[user@pc.local ~]$ sudo dnf update 
[sudo] пароль для user: 
Russian Fedora for Fedora 25 - Free - Updates                                  1.0 MB/s | 138 kB     00:00    
Russian Fedora for Fedora 25 - Nonfree                                         2.0 MB/s | 306 kB     00:00    
Russian Fedora for Fedora 25 - Nonfree - Updates                               1.7 MB/s | 232 kB     00:00    
RPM Fusion for Fedora 25 - Nonfree - Updates                                   276 kB/s |  23 kB     00:00    
RPM Fusion for Fedora 25 - Free - Updates                                      2.2 MB/s | 265 kB     00:00    
Russian Fedora for Fedora 25 - Fixes - Updates                                 450 kB/s |  46 kB     00:00    
Russian Fedora for Fedora 25 - Fixes                                           494 kB/s |  54 kB     00:00    
Russian Fedora for Fedora 25 - Free                                            2.1 MB/s | 335 kB     00:00    
Fedora 25 - x86_64 - VirtualBox                                                 60 kB/s |  28 kB     00:00    
Yandex                                                                          16 kB/s | 1.6 kB     00:00    
RawTherapee Home Project (Fedora_25)                                           235 kB/s |  95 kB     00:00    
Зависимости разрешены.

а где тут закачка 20 мб базы?