Подскажите по обновлению

Может кто-нибудь подсказать, что это значит и почему:

emerge -av sys-libs/glibc
...
Calculating dependencies... done!
[binary   R    ] sys-libs/glibc-2.25-r9:2.2::gentoo  USE="caps gd (multilib) 
nscd rpc -audit -debug (-hardened) -headers-only% -profile (-selinux) -suid 
-systemtap (-vanilla) (-crosscompile_opts_headers-only%)" 19549 KiB

Total: 1 package (1 reinstall, 1 binary), Size of downloads: 19549 KiB

Зачем нужно переустанавливать бинарный glibc?
Если что, у меня в /etc/portage/ вхождений “glibc” ровно 0.
@ @
UPD А cl-update тащит аж 42 пакета со статусами (N) и (rR). Я эту лажу ставить не буду!)) Потому что не понимаю, зачем оно мне нужно?? При этом вывод emerge конкретно отличается:

emerge -uavD world 

Local copy of remote index is up-to-date and will be used.
These are the packages that would be merged, in order:
Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 KiB
Nothing to merge; quitting.

Как это понимать?

С emerge -puvDN --tree world стало немного понятнее (из-за изменения use-флагов и каких именно).

Есть разные способы обновления бинарных пакетов, в т.ч. обноление по дате сборки. Пакеты же пересобираются по любому поводу, в т.ч. при обновлении eclass в портежах или правках ebuild-ов без изменения версии. Это позволяет поддерживать целостность репозитория и минимизировать нестыковки.

Пакеты же пересобираются по любому поводу …

Это точно. Перейду пожалуй на выборочное обновление раз в месяц.

Опять же, из бинарных пакетов лучше обновлять сразу всю систему, а не выборочно ) Пусть хоть раз в месяц.

Alexander Tratsevskiy wrote:

Опять же, из бинарных пакетов лучше обновлять сразу всю систему, а не выборочно ) Пусть хоть раз в месяц.

Возможно оффтопик, но я выбрал этот дистрибутив вовсе не из-за rolling-release, я вообще-то противник роллингов. А потому, что а) без systemd, то есть настоящий GNU/Linux, а не поделки красношапочных, б) можно “исправить” опции сборки конкретного пакета: например в rpm-based вы получаете пакет, в котором включены все возможные опции/зависимости на все возможные случаи, которые вам нафиг не нужны. Наличие кривого Portage, написанного быдлокодерами на их любимом языке программирования конечно огорчает, но до GuixSD я пока не прокачался :wink:

1001 Mhz wrote:

. Наличие кривого Portage, написанного быдлокодерами на их любимом языке программирования конечно огорчает, но до GuixSD я пока не прокачался :wink:

Слишком категорично( Что именно вас не устраивает?

Вячеслав К. wrote:

Слишком категорично(

Это общепризнанная точка зрения :slight_smile: Среди программистов причем!

Что именно вас не устраивает?

Ооо! Я могу написать список пунктов из 5ти как минимум. На первом месте очевидно будет скорость расчета зависимостей.

На первом месте очевидно будет скорость расчета зависимостей.

Удивили ))

На втором блокировки, я прав?

Alexander Tratsevskiy wrote:

На втором блокировки, я прав?

Нет. На втором месте следующая проблема: Portage каждый раз заново строит дерево зависимостей. Каждый раз, при каждом запуске. Зачем?? Это долго и нудно (см. пункт 1). Я бы даже смирился с тормозной работой Portage, если бы оно единожды строило дерево, а потом скажем кэшировало бы его, а еще лучше - записывало бы в какую-нибудь БД. А при установке нового пакета вносились бы инкрементальные изменения. Но это невозможно, я не знаю только, “невозможно в принципе” или “нужно переписывать с нуля”))

А другие три?

А другие три?

Заменю их одним вопросом: кто-нибудь помнит все опции Portage? И может хотя бы приблизительно сказать, к чему приведет запуск emerge с определенным набором ключей, не используя --pretend? Думаю, даже среди продвинутых пользователей таких нету. Я бы назвал подобное не гибкостью Portage, а кишками наружу))

Заменю их одним вопросом: кто-нибудь помнит все опции Portage? И может хотя бы приблизительно сказать, к чему приведет запуск emerge с определенным набором ключей, не используя --pretend? Думаю, даже среди продвинутых пользователей таких нету. Я бы назвал подобное не гибкостью Portage, а кишками наружу))

Могу привести пример с MS Wold и Adobe Illustrator. Секретарю будет достаточно и 2-5% возможностей текстового процессора, хороший дизайнер будет стремиться освоить большую часть возможностей иллюстратора. При этом оба продукта стремятся быть лучшими в своём классе.

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

Вот ваш пример с MS Wold и Adobe Illustrator весьма характерен. Он как бы намекает, что тут что-то не то… Как там, “одна простая утилита, которая хорошо делает свою работу”? Возможно, портеж следовало бы разбить на отдельные утилиты: одна только собирает из ебилдов и больше ничего не умеет, вторая только обновляет установленные пакеты и при необходимости дергает первую, а просчет зависимостей вообще вынести в отдельную библиотеку. А потом по отдельности переписать все на C :slight_smile:

Если бы пакетный менеджер работал быстро, мы бы не задумывались над тем, как можно в несколько раз:

  • ускорить время просчёта обновления
  • снизить трафик для выполнения проверки обновления
  • ускорить выполнение обновления

а так же добавить поддержку быстрого отката обновления. Всего этого можно добиться не переписывая пакетный менеджер. Вопрос времени.