- Linux для человеков!
- Обзоры
- Фотогалереи
- Помощь при использовании сайта
- Новое из блога
- Обновление Gentoo Linux
- HOWTO Полное обновление системы
- Приведение в порядок /var/lib/portage/world
- Обновление profile
- USE-флаги
- Запуск обновления системы (если не нужно обновлять toolchain)
- Некоторые причины не использовать emerge -U вместо -u
- Обновление одного из пакетов входящих в toolchain
- Обновление безопасности.
- Удаление неиспользуемых пакетов.
- Обновление конфигов.
- Руководство Gentoo Linux по обновлению GCC
- 1. Введение
- 2. Общие указания по обновлению
- 3. Переход с GCC-3.3 на 3.4 или более новый
- 4. Обновление GCC на новой установке
- 5. Обычные грабли
Linux для человеков!
Обзоры
Фотогалереи
Помощь при использовании сайта
Новое из блога
Обновление Gentoo Linux
Обновление Gentoo Linux несколько нетривиально по сравнению с другими дистрибутивами. В user-friendly дистрибутивах таких как Mandriva, OpenSUSE, Ubuntu за Вас все сделает менеджер управления пакетами, достаточно лишь озадачить его этим. В Gentoo Linux также имеется система управления пакетами под названием Portage которая разруливает зависимости и делает процесс обновления намного легче чем например в Slackware.
Однако в силу того что Gentoo является source-based дистрибутивом (весь софт компилируется из исходных кодов) появляются некоторые особенности. Например Вы не сможете обновить ядро автоматически как в Ubuntu где оно поставляется одинаковым для всех.
Для начала нам нужно иметь работающее подключение к интернету и прописанную переменную адреса сервера в файле /etc/make.conf с которого будет обновляться дерево portage. Я обновляюсь с зеркала яндекс поэтому в make.conf прописал именно его
Следующим шагом нужно синхронизировать дерево портов командой
Далее запускаем полное обновление системы с учетом всех зависимостей:
Portage выведет список всех доступных обновлений с указанием версий пакетов и используемых USE флагов
Если список используемых USE флагов и пакетов для обновления Вас устраивает можно начать сборку.
В качестве небольшого хинта: Для того чтобы не писать каждый раз emerge и некоторые его постоянно использующиеся ключи я добавил алиасы (добавочные имена) в файлы
.bashrc и .bash_profile. Чтобы в будущем упростить ввод впишем в вышеназванные файлы строчку
будет соответствовать команде
Если в списке обновляемых пакетов есть хотя бы один из составляющих toolchain (glibc, gcc, binutils, linux-headers), то желательно пересобрать эти пакеты два раза, после чего пересобрать весь мир (world).
На самом деле это не обязательно по крайней мере если после обновления тулчейна все ПО работает также стабильно. Делается это в основном потому что glibc и другие пакеты из toolchain используются для сборки всех остальных пакетов и пересборка мира новым тулчейном позволит использовать преимущества имеющиеся в новой версии в масштабе всей системы.
Мантейнеры Gentoo конечно заботятся о пользователях и выпускают собственные патчи для того чтобы все пакеты собирались нормально, но все же иногда (возможно по недосмотру пользователя) отдельные пакеты отказываются собираться без вмешательства юзера, например как здесь.
Для того чтобы продолжить сборку с того же места где она остановилась запускаем
Если все же причину мешающую сборки устранить не удалось, то можно пропустить поблемный пакет продолжив без него
После удачной сборки не забываем запустить скрипт
который произведет в системе поиск исполняемых файлов со сломанными зависимостями и пересобрав их сделает перелинковку. Заключительным этапом будет запуск
который проверит наличие изменений в конфигурационных файлах и найдя их предоставит Вам возможность оставить конфиги как есть, заменить новыми или заменить на новые с ручной правкой.
На этом пожалуй закончу, если у Вас есть замечания и предложения по статье — пишите, возможно я что то забыл.
Источник
HOWTO Полное обновление системы
Ссылка на оригинал:
Приведение в порядок /var/lib/portage/world
В world должен быть список программ, которые нужно доустановить к тем, которые уже входят в «system» (т.е. в текущий профайл).
в world не должно быть никаких библиотек, и т.д., которые не нужны сами по себе, а нужны только для удовлетворения чьих-то зависимостей (чтобы не продолжать устанавливать/обновлять их, если они уже станут не нужны по какой-то причине) ;
программ, которые уже входят в » system «, не должно быть в world
в world нельзя указывать определенную версию софта, это лучше делать в /etc/portage/package.mask ;
скрипт regenworld может помочь восстановить world путем анализа /var/log/emerge.log и генерации на его базе файла world (он перезапишет текущий world!) ;
скрипт dep -p -w (входящий в состав пакета udept ) поможет найти избыточные записи в world (которые всё-равно нужны другим записям в world или входят в system );
перед серьёзными обновлениями желательно просмотреть /etc/portage/ * , т.к. там могут быть уже не актуальные записи мешающие текущему обновлению.
Обновление profile
Не каждый Gentoo release включает в себя новый profile (например, 2004.1 был без profile).
Даже если новый profile есть, то переходить на него не обязательно (если это будет обязательно, то старый профайл будет «протестующий» (deprecated) и emerge об этом должен будет громко кричать).
Инструкции по обновлению profile будут выкладываться здесь: http://www.gentoo.org/doc/ru/gentoo-upgrading.xml и как правило сводиться к изменению симлинка /etc/make.profile
USE-флаги
Запустить emerge -uDpv —newuse world и проверить что USE-флаги для всех пакетов выставлены корректно, и при необходимости скорректировать
USE-флаги выставляются в /etc/make.conf и /etc/portage/package.use
Запуск обновления системы (если не нужно обновлять toolchain)
emerge -puDav —newuse world
показывает что будет обновляться пакет входящий в toolchain (linux-headers, glibc, binutils или gcc), то крайне рекомендуется полностью перекомпилировать всю систему — см. следующий пункт — а иначе можно вместо следующего пункта просто запустить:
emerge -uDav —newuse world
Некоторые причины не использовать emerge -U вместо -u
Причина 1: Проблемы со SLOT
Это, к примеру, происходит потому, что некоторые люди хотели gimp-2 вместо gimp-1.2 . Представьте ситуацию, где gimp-1.2 помечен stable и находится в SLOT 1, gimp-2 помечен unstable и находится в SLOT 2. Теперь при выполнении ACCEPT_KEYWORDS=
x86 emerge gimp получите gimp-2 .
Позже, когда вы посчитаете, что наступило время обновить свою систему чем-либо похожим на «emerge -U world», эта команда установит gimp-1.2, потому, что gimp находится в world-файле, и флаг «-U» не обрабатывает SLOT должным образом.
Причина 2: Проблемы, в случае удаления ebuild-ов с Portage-дерева.
Допустим, в Portage находятся 2 версии пакетов foo, foo-1.4 (помеченный как stable) и foo-1.6 (помеченный как unstable). Вы хотите вариант unstable и делаете emerge, как с вышеуказанным gimp. Позже обновляете world как было сказано выше, но в промежутке этого времени вышло критическое обновление для foo-1.6 — foo-1.6.1. Теперь появляется несколько возможностей обработки.
foo-1.6 был удален из Portage. Будет установлен foo-1.4, несмотря на «снижение» версии вместо флага «-U»
Ситуация будет еще хуже, если foo-1.6 не был удалён из Portage по какой-либо причине: foo-1.6 (тот, что с критической уязвимостью) будет оставаться на вашей системе до тех пор, пока не будет помечено stable что-либо выше чем foo-1.6.
Предупреждение: Не рекомендуется использовать ACCEPT_KEYWORDS=
x86 emerge foo о чем можно почитать здесь http://www.gentoo.org/doc/ru/gentoo-amd64-faq.xml#keyword
Обновление одного из пакетов входящих в toolchain
Если обновляется хотя-бы один из linux-headers, glibc, binutils или gcc , то рекомендуется пересобрать их дважды, после чего весь system , после чего весь world .
Примечание: Цель двойной компиляции toolchain — получить гарантированно стабильный и корректный toolchain не зависящий от предыдущего. Перекомпилировать system/world после этого жёсткой необходимости нет, по крайней мере если остальной софт продолжает работать (возможно даже используя библиотеки из старого toolchain — см. предыдущие пункты об апгрейде).
Цель перекомпиляции system/world — чтобы весь софт получил потенциальное преимущество от установки нового toolchain . system перекомпилируется перед world из тех-же соображений, т.к. при компиляции программ из world используются утилиты из system .
Если увеличивается первая или вторая цифра версии gcc , то перед второй сборкой нужно переключиться на новую версию через gcc-config — иначе новый gcc просто установится параллельно со старым в «новый слот», но по умолчанию использоваться будет старый.
При сборке system после двойной перекомпиляции toolchain нет необходимости опять компилировать toolchain как часть system. Аналогично при сборке world после system нет небходимости опять компилировать пакеты из system как часть world. Это можно попробовать обойти либо вручную, либо используя скрипты [1], либо через бинарные пакеты и ` emerge -k ` (я предпочитаю последний вариант).
Итак, рекомендованный набор команд:
Листинг 1 . Рекомендованный набор команд
Примечание: Чисто теоретически существует пакет binutils-config , который когда-нибудь может потребоваться использовать аналогично gcc-config .
Обновление безопасности.
Примечание: Даже после ` emerge -uDav —newuse world ` в системе могут оставаться устаревшие пакеты с дырами в безопасности — в слотах!
Удаление неиспользуемых пакетов.
После обновления системы в ней могут оказаться пакеты, которые никто не использует. Эти пакеты желательно удалить, т.к. они не будут в дальнейшем обновляться при ` emerge -uDav —newuse world `.
После обновления библиотек может потребоваться перекомпилировать программы, которые эти библиотеки используют:
Примечание: Для glsa-check , revdep-rebuild необходимо установить пакет gentoolkit
Обновление конфигов.
Если используется runit-init и обновлялся пакет baselayout , то нужно восстановить /sbin/init:
Отслеживание важных сообщений при установке пакетов.
В процессе emerge world выдаётся очень много сообщений, причём важные комментарии перемешаны с командами компиляции, и отследить их при сборке нескольких пакетов одновременно невозможно.
Но все эти сообщения можно получить из log-файлов после окончания установки emerge world . Для этого нужно использовать либо enotice , либо portlog-info .
Руководство Gentoo Linux по обновлению GCC
1. Введение
Зачем нужно обновлять? Ну, GCC довольно похож на любой другой пакет в вашей системе, но чуточку более важен. GCC следует обновлять всякий раз, когда в новой версии исправляются какие-нибудь раздражающие вас ошибки, добавляется новые нужные функции, или если вы хотите держать свою систему обновленной. Если ни один из этих случаев к вам не относится, обновление можно спокойно откладывать, пока ваша версия GCC поддерживается разработчиками Gentoo.
Если вы устанавливаете новую версию GCC, система не переключается на ее использование автоматически. Вам необходимо явно запросить изменение, потому что в процессе перехода может потребоваться несколько дополнительных шагов. Если вы решите не переключаться, система Portage продолжит использовать более старую версию компилятора, пока вы не передумаете или пока не удалите старый компилятор из своей системы.
В этом руководстве описываются необходимые шаги, нужные для полноценного обновления компилятора, используемого вашей системой Gentoo. Отдельный раздел посвящен переходу с GCC 3.3 на 3.4 или более новые версии и проблемам с libstdc++. Другой частный раздел предназначен пользователям, впервые устанавливающим Gentoo из архива третьей стадии (stage3), после выхода новой версии GCC.
Примечание: Необходимо заметить, что обновление с GCC-3.4 до GCC-4.0 или более нового не требует существенных изменений от пользователя, так как GCC-3.4 и GCC-4.0 используют одинаковый двоичный прикладной интерфейс (ABI). Все что нужно, это использовать gcc-config, чтобы выбрать желаемый компилятор.
2. Общие указания по обновлению
Важно: Если вы ищете подробные указания по обновлению с GCC-3.3 на GCC-3.4 или более новый, обратитесь к соответствующему разделу.
Важно: Если вы ищете подробные указания по обновлению GCC на вновь установленных системах, обратитесь к соответствующему разделу.
Вообще говоря, переход на версии с исправленными ошибками (bugfix release), как с 3.3.5 на 3.3.6, должен быть довольно безопасен: надо только установить новую версию, переключиться на нее и пересобрать единственный затрагиваемый пакет — libtool. Однако, при некоторых обновлениях GCC нарушается двоичная совместимость, в таких случаях может потребоваться пересборка не только затрагиваемых пакетов, но и даже всего системного набора и пакетов, необходимых для компиляции.
Говоря о необходимости ручного переключения на новую версию компилятора, мы сказали, что оно не происходит автоматически. Тем не менее, есть одно исключение — переход на версию с исправленными ошибками (как с 3.3.5 на 3.3.6), если не используется режим «multislot», позволяющий обеим версиям сосуществовать в одной системе. По умолчанию этот режим выключен, ведь большинству пользователей он ничего не даcт.
Листинг 2.1: Обновление GCC
(Вместо «i686-pc-linux-gnu-3.4.5» укажите обновленную
версию GCC и настройки CHOST)
# emerge —oneshot -av libtool
Теперь пересоберите набор программ для компиляции, затем world, используя новый компилятор.
Листинг 2.2: Пересборка системы
# emerge -eav system
# emerge -eav world
Теперь можно без опасений удалить старую версию GCC. Если вы чувствуете такую необходимость, введите следующую команду (как обычно, вместо =sys-devel/gcc-3.3* укажите версию, которую собираетесь удалить):
Листинг 2.3: Удаление более старой версии GCC
# emerge -aC =sys-devel/gcc-3.3*
3. Переход с GCC-3.3 на 3.4 или более новый
Переход с GCC-3.3 на 3.4 или более новую версию не так гладок, ведь между этими версиями изменился двоичный прикладной интерфейс C++ (ABI). Также придется позаботиться о существующей проблеме с библиотекой libstdc++.
Важно: Если вы обновляете GCC на машине SPARC, вам придется выбрать путь полной пересборки системы из-за некоторых внутренних изменений двоичного интерфейса (ABI) GCC в области передачи параметров функций.
У вас есть два варианта обновления системы. Первый способ быстрее и требует использования программы revdep-rebuild из пакета gentoolkit, а во втором вся система пересобирается с нуля, чтобы задействовать новые возможности GCC. Ваше дело, какой из способов выбрать. В большинстве случаев первого способа достаточно.
Если вы выбрали этот способ, нужно сначала установить gentoolkit, если вы еще этого не сделали. Затем обновите GCC и переключите систему на новый компилятор. Также пересоберите пакет libtool, чтобы обеспечить пригодность программ для компиляции.
Листинг 3.1: Установка gentoolkit и обновление GCC
# emerge -an gentoolkit
(вместо «i686-pc-linux-gnu-3.4.5» укажите обновленную
версию GCC и настройки CHOST)
# emerge —oneshot -av libtool
Теперь посмотрите, какие пакеты собирается пересобирать revdep-rebuild. Затем запустите revdep-rebuild на собственно пересборку. Это займет некоторое время, так что потерпите.
Листинг 3.2: Использование revdep-rebuild
# revdep-rebuild —library libstdc++.so.5 — -p -v
# revdep-rebuild —library libstdc++.so.5
Примечание: Возможно, у вас появятся проблемы с несуществующими версиями пакетов из-за того, что они устарели или замаскированы. В этом случае можно при запуске revdep-rebuild указать параметр —package-names. Это заставит пакеты пересобираться, основываясь на именах пакетов, вместо точного имени и версии.
Для обеспечения совместимости с более старыми двоичными приложениями C++ и любыми пакетами, которые revdep-rebuild мог пропустить, надо установить пакет sys-libs/libstdc++-v3 до того, как удалять GCC 3.3 из своей системы.
Листинг 3.3: Установка libstdc++-v3 и удаление GCC
# emerge —oneshot sys-libs/libstdc++-v3
# emerge -aC =sys-devel/gcc-3.3*
Использование emerge -e
Этот гораздо более медленный способ пересобирает всю систему, гарантируя, что все пересобирается новым компилятором, и, таким образом, он безопаснее. Сперва потребуется обновить GCC и libtool, и переключить систему на новый компилятор.
Листинг 3.4: Обновление GCC
(вместо «i686-pc-linux-gnu-3.4.5» укажите обновленную
версию GCC и настройки CHOST)
# emerge —oneshot -av libtool
Для обеспечения совместимости с более старыми двоичными приложениями C++, надо установить в систему пакет sys-libs/libstdc++-v3.
Листинг 3.5: Установка libstdc++-v3
# emerge —oneshot sys-libs/libstdc++-v3
Теперь займемся пересборкой сначала пакетов system, а затем world. Это займет очень длительное время, зависящее от количества установленных пакетов: ведь будут пересобираться все средства компиляции и поддерживающие системные файлы, а затем каждый пакет, находящийся в вашей системе. Это необходимо, чтобы все пакеты были гарантированно скомпилированы уже с новыми средствами компиляции, включая сами эти средства.
Листинг 3.6: Пересборка system и world
# emerge -e system
Теперь можно удалить старые версии GCC, не вызывая проблем:
Листинг 3.7: Очистка
# emerge -aC =sys-devel/gcc-3.3*
4. Обновление GCC на новой установке
Обновление GCC в системе после установки из архива третьей стадии (stage3) — дело простое. Отсутствие изобилия установленных программ, которые ссылаются на старую версию GCC — это преимущество пользователей, только что установивших систему. В следующем примере показывается обновление с GCC-3.3 на 3.4 или более новые версии. При обновлении с других версий GCC будут кое-какие отличия. Например, имена библиотек, используемые ниже для revdep-rebuild, относятся к версии GCC 3.3, также, как и необходимость установки libstdc++-v3.
Пока пользователь не внес каких-либо изменений в систему, для получения системы с новой версией GCC нужно всего несколько шагов. Также, как и при обновлении с GCC-3.3 до 3.4, у пользователя есть две возможности. Но, в отличие от обновления с GCC-3.3 до 3.4, здесь обновление проще, так как различий между способами меньше. Первый способ быстрее, и задействует программу revdep-rebuild из пакета gentoolkit, подобно вышеописанной процедуре обновления. Использование revdep-rebuild предполагает пересборку только тех пакетов, которые действительно ссылаются на библиотеки GCC, тогда как при втором способе система полностью перекомпилируется с новой версией GCC, что занимает намного больше времени. Второй способ никогда не потребуется, и описан только для полноты картины.
Приведенные первые шаги одинаковы для обоих способов, и должны делаться в любом случае.
Листинг 4.1: Обновление GCC
(вместо «i686-pc-linux-gnu-3.4.5» укажите обновленную
версию GCC и настройки CHOST)
# emerge —oneshot -av libtool
Для обеспечения совместимости с более старыми двоичными приложениями C++, надо установить в систему пакет sys-libs/libstdc++-v3.
Листинг 4.2: Установка libstdc++-v3
# emerge —oneshot sys-libs/libstdc++-v3
Этот способ требует, чтобы вы сначала установили пакет gentoolkit, если это еще не сделано. Затем запустите программу revdep-rebuild, чтобы просканировать установленные пакеты, найти и пересобрать нужные.
Листинг 4.3: Установка gentoolkit и запуск revdep-rebuild
# emerge -an gentoolkit
# revdep-rebuild —library libstdc++.so.5 — -p -v
# revdep-rebuild —library libstdc++.so.5
Примечание: Возможно, у вас появятся проблемы с несуществующими версиями пакетов из-за того, что они устарели или замаскированы. В этом случае можно при запуске revdep-rebuild указать параметр —package-names. Это заставит пакеты пересобираться, основываясь на именах пакетов, вместо точного имени и версии.
Использование emerge -e
Этот способ, будучи гораздо медленнее, пересобирает всю систему, гарантируя, что все пересобрано новым компилятором. Это необязательно, но допустимо, если вы также изменяете переменную среды CFLAGS или другие переменные make.conf, которые влияют на компиляцию системы.
Так как эти действия выполняются сразу после первоначальной установки, не потребуется перекомпилировать world, как мы поступили бы для обновления компилятора в ранее установленной системе. Однако, для пущей уверенности в том, что обновлены все пакеты, можно запустить обновление цели world вместо system.
Листинг 4.4: Пересборка system
# emerge -e system
Теперь можно удалить старые версии GCC, не вызывая проблем. Выражение ВАША-НОВАЯ-ВЕРСИЯ-GCC замените номером версии, на которую вы перешли:
Листинг 4.5: Очистка
5. Обычные грабли
Важно на время обновления отключить distcc. Смешение версий компилятора на разных узлах вызовет проблемы при сборке. Это не относится к ccache, так как объекты кэша будут в любом случае сделаны недействительными.
Всегда используйте одну и ту же версию GCC для своего ядра и дополнительных модулей ядра. Как только вы пересоберете world с новым GCC, внешние модули (например, app-emulation/qemu-softmmu) не смогут загрузиться. Пожалуйста, чтобы это исправить, пересоберите свое ядро новой версией GCC.
Если вы обновляете GCC на машине SPARC, обязательно еще раз запустите silo -f после пересборки world, чтобы избежать возможных проблем.
Распространенные сообщения об ошибках
Если ваша система жалуется на что-то вроде libtool: link: `/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.la’ is not a valid libtool archive, запустите /sbin/fix_libtool_files.sh 3.3.6 (замените «3.3.6» на номер версии из сообщения об ошибке).
Если вы увидели error: /usr/bin/gcc-config: line 632: /etc/env.d/gcc/i686-pc-linux-gnu-3.3.5: No such file or directory, тогда попробуйте удалить /etc/env.d/gcc/config-i686-pc-linux-gnu и снова запустить gcc-config, следом указав source /etc/profile. Делайте это только тогда, когда у вас не настроены никакие кросс-компиляторы.
Если при emerge -e system или emerge -e world не собирается пакет, выполнение можно продолжить командой emerge —resume. Если ошибка появляется снова и снова, пропустите пакет, указав emerge —resume —skipfirst. Не запускайте параллельно другие экземпляры emerge, чтобы не потерять информацию, нужную для возобновления.
Если во время обновления компиляторв встретится ошибка spec failure: unrecognized spec option, попробуйте откатиться на свой компилятор по умолчанию, убрать переменную GCC_SPECS и снова обновить компилятор:
Листинг 5.1: Восстановление первичной настройки компилятора
Источник