Зачем нужно переустанавливать бинарный 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.
Есть разные способы обновления бинарных пакетов, в т.ч. обноление по дате сборки. Пакеты же пересобираются по любому поводу, в т.ч. при обновлении eclass в портежах или правках ebuild-ов без изменения версии. Это позволяет поддерживать целостность репозитория и минимизировать нестыковки.
Опять же, из бинарных пакетов лучше обновлять сразу всю систему, а не выборочно ) Пусть хоть раз в месяц.
Возможно оффтопик, но я выбрал этот дистрибутив вовсе не из-за rolling-release, я вообще-то противник роллингов. А потому, что а) без systemd, то есть настоящий GNU/Linux, а не поделки красношапочных, б) можно “исправить” опции сборки конкретного пакета: например в rpm-based вы получаете пакет, в котором включены все возможные опции/зависимости на все возможные случаи, которые вам нафиг не нужны. Наличие кривого Portage, написанного быдлокодерами на их любимом языке программирования конечно огорчает, но до GuixSD я пока не прокачался
Нет. На втором месте следующая проблема: Portage каждый раз заново строит дерево зависимостей. Каждый раз, при каждом запуске. Зачем?? Это долго и нудно (см. пункт 1). Я бы даже смирился с тормозной работой Portage, если бы оно единожды строило дерево, а потом скажем кэшировало бы его, а еще лучше - записывало бы в какую-нибудь БД. А при установке нового пакета вносились бы инкрементальные изменения. Но это невозможно, я не знаю только, “невозможно в принципе” или “нужно переписывать с нуля”))
Заменю их одним вопросом: кто-нибудь помнит все опции Portage? И может хотя бы приблизительно сказать, к чему приведет запуск emerge с определенным набором ключей, не используя --pretend? Думаю, даже среди продвинутых пользователей таких нету. Я бы назвал подобное не гибкостью Portage, а кишками наружу))
Заменю их одним вопросом: кто-нибудь помнит все опции Portage? И может хотя бы приблизительно сказать, к чему приведет запуск emerge с определенным набором ключей, не используя --pretend? Думаю, даже среди продвинутых пользователей таких нету. Я бы назвал подобное не гибкостью Portage, а кишками наружу))
Могу привести пример с MS Wold и Adobe Illustrator. Секретарю будет достаточно и 2-5% возможностей текстового процессора, хороший дизайнер будет стремиться освоить большую часть возможностей иллюстратора. При этом оба продукта стремятся быть лучшими в своём классе.
Ваш третий и второй вопросы, как и четвёртый с пятым намекают на то, что надо упростить портежи чтобы ускорить просчёт зависимостей.
Вот ваш пример с MS Wold и Adobe Illustrator весьма характерен. Он как бы намекает, что тут что-то не то… Как там, “одна простая утилита, которая хорошо делает свою работу”? Возможно, портеж следовало бы разбить на отдельные утилиты: одна только собирает из ебилдов и больше ничего не умеет, вторая только обновляет установленные пакеты и при необходимости дергает первую, а просчет зависимостей вообще вынести в отдельную библиотеку. А потом по отдельности переписать все на C