Добрый день!
Удалил пакет app-misc/cldg-meta дабы удаленные приложения при обновлениии не устанавливались повторно. После этого обновляются только пакеты, которые устанавливались мною. Подскажите как в этом случае обновлять ВСЮ ситему. Повторная установка app-misc/cldg-meta с USE-флагами и флагами в make.conf не помогают.
А как вы обновляетесь?
emerge -uD world
emerge -uD system
Просто непонятна фраза “…Удалил пакет app-misc/cldg-meta дабы удаленные приложения при обновлениии не устанавливались повторно”
Зачем?? Вы тем самым нарушили нормальную структуру дистрибутива.
для удаления пакетов есть другие пути, например http://www.calculate-linux.org/boards/7/topics/4810
Про обновление ВСЕЙ системы вопрос уже поднимали здесь http://www.calculate-linux.org/boards/16/topics/5248
Подправил packages.provided (добавил версии пакетов) и вернул app-misc/cldg-meta. После этого emerge u @installed попросил пересобрать dev-java/antlr и ругнулся на пару заблокированных пакетов исправил и стартонуло обновление! Спасибо SSid none за наводку.
Решил поднять тему для обсуждения автоматического или полуавтоматического обновления системы.
Недавно перешел на Calculate Linux Desktop GNOME, система нравиться, но я не нашел в ней утилиты автообновления системы, подобной утилитам в пакетных дистрибутивах, для поддержания ОС в актуальном состоянии.
Перекопав некоторое количество документации и рекомендаций написал скрипт:
#!/bin/bash
# Скрипт для обновления системы
# По крайней мере, так как я сейчас это понимаю.
# Обновляем дерево портежей и оверлея Calculate.
echo "Выполнение eix-sync"
eix-sync
# Обновляем системные программы, а потом систему в целом, учитывая зависимости.
echo "Выполнение emerge -aDu system"
emerge -aDu system
echo "Выполнение emerge -aDu world"
emerge -aDu world
# Так как emerge иногда не разрешает зависимости полностью, используем:
echo "Выполнение revdep-rebuild"
revdep-rebuild
# По окончании посмотрим изменившиеся конфиги
echo "Выполнение dispatch-conf"
dispatch-conf
Прошу совета: все ли сделано правильно и можно ли сделать лучше? 
Тут я бы ещё добавил в конце:
emerge --depclean
Поддерживаемый с недавних пор репозиторий бинарных пакетов вносит свои коррективы в процесс обновления. Вы можете выбирать, использовать его или нет путем выбора профиля командой:
eselect profile set X
Список профилей можно посмотреть так:
eselect profile listпервое: что cделает emerge с дополнением -a ?
второе: допишите, что подобный скрипт должен выполнятся из-под root или sudo
а если человек сидит на медленном/не безлимитном интернете, то в качестве предварительного -pv (узнать во сколько обойдется подобное обновление), то же касается и revdep-rebuild
emerge --depclean тоже желательно вначале запустить с -p (надо просмотреть, что удаляешь)
суммируя вышеизложенное - желательно перед каждой командой запускать её аналог с -p и требования подтверждения выполнения
третье: при обновлении не лишним добавить приставку -N
четвертое: в самом конце можно ещё приплюсовать eclean-dist
так же не понятно зачем поочередно проводить emerge -aDu system и emerge -aDu world? второе включает в себя первое.
Александр, огромное спасибо за советы, с профилями ознакомился только после Вашей подсказки… :-[
Пожалуй с профилей и начну: Прекрасно придуманная система, которая позволяет в практически gentoo-системе использовать бинарные пакеты. Одно сплошное восхищение! Но увы, calculate-way уже узнал в моем лице своего нового адепта и мой, далеко не новый HP Compaq NX6110, шустрее исполняет то, что скомпилировал сам. Как пример могу привести пакет openoffice - разница в производительности между ним и его бинарным вариантом была заметна невооруженным глазом, особенно при открытии больших документов и таблиц и работе с ними. Извините за лирический оффтоп.
*emerge -depclean* опасаясь от него деструктивности оставлял его изучение и применение “на потом”, но вчера взялся.
В результате остановился на варианте emerge --depclean --ask, где –ask или *a* выводит сообщение о предстоящих действиях, после чего предлагает пользователю продолжить или отменить действия.
SSid none, по моему мнению, использовать –ask удобнее, нежели –pretend, так как вычисление зависимостей происходит один раз и после этого можно сразу принять решение, не запуская emerge повторно. Вы согласны?
Есть с –depclean и тонкие моменты:
- В англоязычных мануалах есть фраза: “As a consequence, it is often necessary to run emerge --update --newuse --deep
world prior to depclean." Все русскоязычные источники переводят её как: "В последствии, после выполнения depclean, очень часто требуется выполнить emerge --update --newuse --deepsystemworld." Думаю, что более верным, учитывая предыдущее предложение, будет такой вариант: "Вследствие, часто бывает необходимо выполнить emerge --update --newuse --deepworld до depclean.” А учитывая действие опцииN* (SSid none, спасибо за совет!) смысл становиться понятным и логичным"убедитесь, что пакеты с измененными флагами есть или будут помещены в@world* ДО запуска очистки". Жду Ваших мнений.
- Переводивший(ие) так же, как и я, запутались, посчитав что сет system не включен в сет world Кстати, отдельная благодарность SSid none за последний вопрос, заставивший меня обратить внимание на этот момент.
SSid none по Вашему второму пункту - согласен, мое упущение! По четвертому - “Спасибо!”, обязательно приплюсую.
Обновленный скрипт выложу вечером или завтра.
Поделюсь и я своим способом. Дело в том, что после обновления некоторых пакетов выводится полезная инфа, которую желательно в некоторых случаях сразу пустить в ход. Таким образом может быть полезно обновлять не всю систему, а по нескольку пакетов (по 1-2-5-10-20, как будет удобнее).
Перед обновлением системы синхронизируем дерево портежей командой eix-sync . После синхронизации автоматом без нашей помощи вызовется eix-diff, который выведет все доступные новые пакеты, которые можно обновить/даунгрейдить. Если вы регулярно обновляете систему, то выхлоп eix-diff можно использовать для того, чтобы разу же “заемержить” обновки.
Получить список пакетов, которые доступны для обновления, можно командой eix -uI. Если их немного - запускаем emerge -av <сюда копируем пакеты из выхлопа eix -uI>. Если пришли обновления целой группы пакетов из одной категории, например dev-perl, то запускаем emerge -auv $(qlist -IC dev-perl/*) , однако заметим, что в таком случае все установленные пакеты из этой группы будут добавлены в @world
Alexey Kazakov, спасибо, с eix попозже буду разбираться дополнительно. Поясню - почему.
Судя по завершающей части консольного вывода eix-sync (приложил в файле, выделив вызовы строками #), он последовательно вызывает eix-update и eix-diff.
Если сразу после этого выполнить emerge -DNpu world (или emerge -аDNu world), будут предложены для обновления пакеты, которые eix-diff пометил как []{lang=“U”}, а eix -uI предлагает более обширный список. Это мне пока непонятно.
Сейчас застрял на двух вопросах:
- Есть ли для emerge разница между “world” и “@world”?
- Если system входит в world, то почему тут [[http://www.calculate-linux.ru/main/ru/system_update_guide#Обновление~~всех~~пакетов]], и в некоторых других источниках эти сеты рекомендуют обновлять раздельно?
Для понимания этой ситуации попробую несколько дней выполнять:
eix-sync
emerge -DNpu world
emerge -DNpu @world
emerge -DNpu system
emerge -DNpu @system
и смотреть как изменяется список пакетов. Очень хочется разобраться.
cons_eix-sync.txt (3.35 KB)
Если сразу после этого выполнить emerge -DNpu world (или emerge -аDNu world), будут предложены для обновления пакеты, которые eix-diff пометил как [U], а eix -uI предлагает более обширный список. Это мне пока непонятно.
скорее всего это объясняется тем, что eix -uI выводит все пакеты в системе, которые можно обновить, а вот сет @world тянет за собой не все пакеты, которые в системе существуют, поэтому emerge -аvDNu world обновит не всё, а только то, что тянется в @world
Сергей Горошилов wrote:
- Если system входит в world, то почему тут [[http://www.calculate-linux.ru/main/ru/system\_update\_guide\#Обновление~~всех~~пакетов\]], и в некоторых других источниках эти сеты рекомендуют обновлять раздельно?
скорее всего затем, что после пересборки системных пакетов (например таких, как perl, python, пакетов, связанных с X-сервером) могут потребоваться дополнительные действия, которые желательно произвести ДО установки дополнительных пакетов, а в некоторых случаях и повторно произвести emerge system
Выложу ответы на свои глупые вопросы, для будущих новичков:
- Для Portage 2.2.0_alpha8 и Portage 2.2.0_alpha9 разницы между названием сета с префиксом “@” и без него нет. Видимо, сейчас это осталось традицией с ранних версий. Однако, поскольку в документации к утилите emerge явно указано:
Когда сет используется в качестве аргумента к emerge, он должен иметь префикс @.
думаю, что нужно делать именно так и буду этого придерживаться.
2. SSid none wrote:
скорее всего затем, что после пересборки системных пакетов (например таких, как perl, python, пакетов, связанных с X-сервером) могут потребоваться дополнительные действия, которые желательно произвести ДО установки дополнительных пакетов, а в некоторых случаях и повторно произвести emerge system
Может быть внести эту цитату в руководство по обновлению системы (http://www.calculate-linux.ru/main/ru/system\_update\_guide), чтобы больше этот вопрос не возникал у переходящих с пакетно-ориентированных дистрибутивов?
В данный момент уже 4 дня пользуюсь скриптом, который выкладываю в приложенном файле. Пока единственным замечанием к его использованию стала пересборка пакета openoffice, у которого изменились только флаги. Планирую прикрутить к нему вариант для минимизации трафика, но это - после вдумчивого изучения eix. Еще уровни детализации вывода ввести, тоже не помешает.
Жду Ваших пожеланий и замечаний. )
updater.sh (1.67 KB)
Может быть внести эту цитату в руководство по обновлению системы.
Не всё так просто. По умолчанию Calculate будет предлагать бинарный профиль и преимущественно бинарные обновления. Здесь обновление system уже не так критично. В руководстве можно упомянуть оба типа обновления. Но пока с бинарными пакетами всё только зарождается, до руководства руки не доходят, да и до конца логика ещё не отстроена. На форуме есть раздел Документация, давайте активно дискутировать на эту тему.
“…Может быть внести эту цитату в руководство по обновлению системы”
это как раз не внесешь. Цитата “…что после пересборки системных пакетов могут потребоваться дополнительные действия…” означала только то, что после некоторых обновлений (чаще всего файлов system) высвечиваются рекомендации по совершению определенных дополнительных действий (иногда они пишутся в news, о других полезно знать заранее, как например о python-update), которые никакой скрипт правильно обработать не сможет. Это могут быть и сообщения об установке дополнительных пакетов, переустановке существующих или проведению дополнительной настройки.
просто emerge -uDN хватит ненадолго, рано или поздно начнут всплывать неразрешенные коннфликты, сбои
вот о необходимости чтения сообщений после обновления системы или мира написать стоит причем КРУПНО!
Просьба все комментарии не воспринимать, как сомнение в необходимости создания механизма облегчающего обновление.
Наоборот, вопрос к разработчикам - не планируется введение в Calculate графического менеджера управления пакетами или хотя бы графической оболочки к вышеназванному примеру скрипта (где -system или -world, дополнения типа -a, -p, -v, -D, -N и т.д.) выставляются просто отметкой “галочкой”, причем с комментарием на русском языке?
С предпоследним комментарием не согласен. Можно обновить так:
emerge -uDG world
emerge -cp
И не думать ни о python-update, ни о perl-cleaner ни так же и о том, чтобы что-то удалить или даже добавить.
**_
А вот по поводу GUI уже можно потихоньку задумываться. Опять же, нашими скромными силами эту задачу не решить. Может кто-то захочет поучаствовать в разработке? Пишите: support@calculate.ru
вот о необходимости чтения сообщений после обновления системы или мира написать стоит причем КРУПНО!
Спасибо! В скрипте это обязательно будет.
вопрос к разработчикам - не планируется введение в Calculate графического менеджера управления пакетами
Самое лучшее, что уже есть, ИМХО, app-portage/porthole. Но меня этот инструмент не устроил. Но своим несовершенством вдохновил на искательство в направлении автоматического обновления.
Размышляя о логике обновления с прицелом на GUI, думаю, что необходимо оставить некий минимум настроек-переключателей, к примеру:
- Сохранение трафика - Без сохранения (Или тип соединения: модем - ADSL,LAN)
- Автомат - Интерактив (В автоматическом режиме можно доверить системе парсить вывод команд и предпринимать нужные действия)
- Бинарные - Исходный код (Как предпочтение оператора или администратора)
- Уровень детализации сообщений. (От --quiet до --verbose, учитывая, что при автоматическом режиме (п.2) уровень д.б. --verbose)
Над усовершенствованием логики скрипта буду работать, но не будучи программистом, пока даже не представляю как реализовать п.2. А для графики видимо понадобится 2 утилиты - одна, как виджет, периодически проверяющий изменения в portage и выводящая уведомление о наличии обновлений. И вторая, вызываемая с помощью первой, несущая в себе движок, наброски которого, возможно делаются сейчас.
Я уже много месяцев использую только:
layman -S
eix-sync
emerge -uDp system
emerge -uDp world
revdep-rebuild
emerge --depclean -p
И всё работает, обновляется, таким макаром поставил кеды 4,5,4 обновил операционку до версии 11,0. Никаких, проблем и ошибок не наблюдаю, конечно надо читать вывод после установки и обновления некоторых програм, но читать и выполнять удобно так как обозначено всё зелёным ярким шрифтом. Не понимаю в чём проблема? Не хотелось бы, что бы дистрибутив начал превращаться в подобие убунты из за желания понравится большинству…