Обновление устаревшей инсталяции gentoo, бакап дерева и конфигов
Всего два раза требовалось обновлять очень старые (пол года и больше) инсталяции gentoo, особенно когда установлено очень много пакетов и/или криво собранный список world (когда по малоопытности ошибки зависимостей решал без ключа --oneshot или хотябы не записывал в отдельный файлик список таких пакетов). К сожалению не запомнил, какие проблемы при этом возникали и как я их решал.. помню, очень сильно мешало то, что в дереве отсутствуют ебилды установленных пакетов, причем не только конкретных версий, но даже сами пакеты удалены из дерева. Кажется revdev-rebuild и --depclean отказывались корректно работать и приходилось чуть ли не вручную вычищать систему, почти полная переустановка.
Отсюда вопрос:
1. Чем черевато накопление всех версий ебилдов (заранее ведь не знаешь какие понадобятся) в дереве... путем либо копирование cp -u /usr/portage в соседнюю папку (по уму после любой установки пакетов), на память, с последующим полным копированием назад (rsync по --sync удаляет устаревшие) и запуском emerge --meta? Поможет ли это с вышеописанной проблемой?
2. Какие имеются средства резервного копирования и восстановления конфигов (желательно попакетного, так как слепое копирование /etc опирует лишнее да и недостаточно только его) для автоматической настройки после переустановки системы с нуля (иногда это реально быстрее, чем копошение с блокировками и зависимостями)?
P.S. Как то ведь quickpkg --include-config=y определяет, какие файлы являются конфигами.
3. Какие действия было бы хорошо совершить для облегчения своей (или приемника) жизни в будущем, если инсталяция делается 'на века'?
- Для комментирования войдите или зарегистрируйтесь
Если система ставится раз и
Если система ставится раз и на всегда, то обновлять дерево не надо, тогда все ебилды останутся.
Можешь попробовать поискать старый слепок дерева, где они еще есть.
1. Если все таки синхронизировать дерево, то проще нужные ебилды пихнуть в свой оверлей, оттуда их никто не удалит. Минус у ебилдов удаленных из дерева - в случае проблем, ты будешьрешать их целиком сам.
Проблема будет в другом. Если
Проблема будет в другом. Если все очень запустить, то обновление через 3 года скорее всего будет невозможно. Никто нен заботится об обновлении с очень старых версий программ.
Я когда-то пытался обновить старые стедж для zaurus. Оказалось, что очень старые портежи не могут работать с новыми ebuild'ами, а потому не могут поставить новые портежи. Конечно обойти все это можно, но сложно.
Насколько мне известно, в gentoo нет удобных средств для обновления с большими периодами, только с использованием глубохих знаний linux вообще и gentoo в частности с решением каждой возникающей проблемы в индивидуальном порядке.
P.S. Как вариант, нужно иметь слепок дерева портжей и дистфайлов раз в полгода. Тогда, в случае чего, обновление будет провести легче. Достать старые слепки очень проблематично: для экономии места их просто стирают.
.
Ну... Как там с программами не знаю.
А базовый набор функциональности уже долгое время стабилен (и ИМХО вполне достаточен).
Как там с 3 годами --- не знаю.
Недавно обновлял домашнюю систему. Последнее обновление --- порядка (или чуть больше) года назад.
Дописал в
/etc/make.conf
соответствующий моим предпочтениям флаг-hal
после чего пришлось выполнить# emerge -uDN portage
(мне было лень фантазировать).Далее как обычно (с учётом факторов Времени):
Никаких проблем в процессе обновления (ну кроме текущего дежурного набора граблей) обнаружено не было.
Было бы интересно провести аналогичный эксперимент для трёх- (для ровного счёта лучше четырёх-) летней системы.
ЗЫ: Реальные проблемы --- с обновлением поприетарных поделий (дистрибутивы которых скачиваются ручками после вынужденного соглашения с лицензией), но здесь проблемный интервал не год и даже не полгода.
:wq
--
Live free or die
rPman написал(а):Всего два
есть такая штука как app-portage/udept - выводит лишние строчки /var/lib/portage/world
наверное не очень поняли суть
наверное не очень поняли суть проблемы...
Речь идет о более реальных сроках - месяцы, а не годы, даже просто месяц между emerge -uND повышает шансы появления блокировок или других проблем.. т.е. невозможность запуска этой операции на автомате или сокращение времени на эту операцию (всетаки 'сначала настраиваем потом запускаем длительный процесс' далеко не всегда работает, всеравно где то на первых 3% работы вылетит с глупым или не очень вопросом... а вручную следить за компиляцией, ну это для особых людей с особым складом ума :) в общем нужно повышать качество автообновления, хотябы там где это логично).
Из дерева могут исчезнуть ебилды пакетов, устанавливаемые по зависимостям, т.е. в world их нет. По уму можно сделать автоматическое копирование в оверлей ебилдов только тех пакетов и версий, которые сейчас установлены (ну хотябы по команде eix -i.. или наверное лучше emerge -ep system world ?) но наверняка будут проблемы с зависимостями между старыми ебилдами и новыми (просто возможный временной интервал межу ними теоретически удваивается).
Мне очень нравится идея бакапа конфигов и /var/lib/portage/world, причем критерий выбора пакетов, для которых необходимо копировать не так прост (ну например если этот конфиг исправлялся и пришел не с обновлением системы то его надо бакапить), было бы очень просто переустановить систему из minimal коммандой emerge -uNDqka `cat world.backup` затем скопировать конфиги причем по уму нужно использовать идеологию etc-upfate (старые, из бакапа переименовать в *._cfg0000_*).
P.S. Забыл, перед emerge настройки портежей /etc/portage/* и /etc/make.conf лучше восстановить самыми первыми.
P.P.S. Некоторые действия, требуемые при обновлении и установке могли бы быть и автоматизированы, например требование зависимости со включенным use-флагом, сам бог велел прописать его автоматически (сейчас я в /etc/portage/packages.use ручками прописываю такие пакеты с комментом, какой пакет их пожелал, на будущее), или, например, запуск revdep-rebuild, хотя тут не решенный вопрос, когда именно это делать.
вы сами видимо создали
вы сами видимо создали мешанину из неподдерживаемых пакетов.
etc-update работает в ряде случаев полностью автоматически.
в portage-2.2 есть возможность проверки необходимых USE флагов.
Вы вероятно используете систему не совсем корректным образом, оттуда и все проблемы.
/
Кстати, это "полностью автоматически" не гарантирует правильности, в результате чего итоговое количество проблем только возрастаетЪ.
:wq
--
Live free or die