Alt linux обновление репозитория

В современных системах на базе Linux огромное число общих ресурсов, которыми пользуются сразу несколько программ: разделяемых библиотек, содержащих стандартные функции, исполняемых файлов, сценариев и стандартных утилит и т. д. Удаление или изменение версии одного из составляющих систему компонентов может повлечь неработоспособность других, связанных с ним компонентов, или даже вывести из строя всю систему. В контексте системного администрирования проблемы такого рода называют нарушением целостности системы. Задача администратора — обеспечить наличие в системе согласованных версий всех необходимых программных компонентов (обеспечение целостности системы).

Для установки, удаления и обновления программ и поддержания целостности системы в Linux в первую очередь стали использоваться менеджеры пакетов (такие, как rpm в дистрибутивах RedHat или dpkg в Debian GNU/Linux ). С точки зрения менеджера пакетов программное обеспечение представляет собой набор компонентов — программных пакетов. Такие компоненты содержат в себе набор исполняемых программ и вспомогательных файлов, необходимых для корректной работы программного обеспечения. Менеджеры пакетов облегчают установку программ: они позволяют проверить наличие необходимых для работы устанавливаемой программы компонент подходящей версии непосредственно в момент установки, а также производят необходимые процедуры для регистрации программы во всех операционных средах пользователя: cразу после установки программа может быть доступна пользователю из командной строки и — если это педусмотрено — появляется в меню всех графических оболочек.

Важно

Благодаря менеджерам пакетов, пользователю Linux обычно не требуется непосредственно обращаться к установочным процедурам отдельных программ или непосредственно работать с каталогами, в которых установлены исполняемые файлы и компоненты программ (обычно это /usr/bin , /usr/share/ имя_пакета ) — всю работу делает менеджер пакетов. Поэтому установку, обновление и удаление программ в Linux обычно называют управлением пакетами.

Часто компоненты, используемые различными программами, выделяют в отдельные пакеты и помечают, что для работы ПО, предоставляемого пакетом A, необходимо установить пакет B. В таком случае говорят, что пакет A зависит от пакета B или что между пакетами A и B существует зависимость.

Отслеживание зависимостей между такими пакетами представляет собой серьёзную задачу для любого дистрибутива — некоторые компоненты могут быть взаимозаменяемыми: может обнаружиться несколько пакетов, предлагающих затребованный ресурс.

Задача контроля целостности и непротиворечивости установленного в системе ПО ещё сложнее. Представим, что некие программы A и B требуют наличия в системе компоненты C версии 1.0. Обновление версии пакета A, требующее обновления компоненты C до новой, использующей новый интерфейс доступа, версии (скажем, до версии 2.0), влечёт за собой обязательное обновление и программы B.

Однако менеджеры пакетов оказались неспособны предотвратить все возможные коллизии при установке или удалении программ, а тем более эффективно устранить нарушения целостности системы. Особенно сильно этот недостаток сказывается при обновлении систем из централизованного репозитория пакетов, в котором последние могут непрерывно обновляться, дробиться на более мелкие и т. п. Этот недостаток и стимулировал создание систем управления программными пакетами и поддержания целостности системы.

Источник

Update/p9

Содержание

Обновление [ править ]

0. Сделайте резервную копию системы до начала обновления [ править ]

1. Обновить дистрибутив до самого свежего p8 [ править ]

2. Проверить syslog [ править ]

Пакет sysklogd был удалён из Sisyphus на момент формирования p9. Если Ваша система использует SysV init и sysklogd, а не systemd и journald, следует заранее установить либо rsyslog, либо syslog-ng во избежание удаления sshd (~~altbug #35312~~), или вытягивания по зависимостям systemd и journald.

3. Проверить apt-repo [ править ]

Скорее всего утилита уже была установлена и обновилась на первом шаге, но на всякий случай проверьте наличие:

4. Изменить источники обновления [ править ]

5. Обновиться до p9 [ править ]

Выполните собственно обновление:

6. Перезагрузка [ править ]

7. Удаление устаревших пакетов [ править ]

Следует воспользоваться советами по ссылке APT_в_ALT_Linux/Советы_по_использованию для удаления устаревших пакетов.

Настройки после обновления [ править ]

Альт Образование [ править ]

При обновлении удаляется пакет Lazarus. Установите его после обновления:

Если устанавливали приложения KDE, то удалите sddm , чтобы не было конфликта с LightDM:

LibreOffice [ править ]

В дистрибутивах на Девятой платформе будет использоваться версия Still LibreOffice (а под именем LibreOffice будет собираться версия Fresh). Поэтому замените на LibreOffice-still:

Simply Linux [ править ]

Необходимо удалить конфликтующий пакет libpq5.9 и установить вместо него пакет libpq5:

Обновление с помощью EPM [ править ]

Для обновления с p8 до p9 можно воспользоваться командой epm release-upgrade из пакета eepm [1] :

Команда выполняет все необходимые действия для обновления, в том числе команды, описанные выше в порядке ручного обновления.

В связи с altbug:37672 необходимо сначала обновить версию eepm:

Известные проблемы [ править ]

E: Unknown vendor ID ‘p9’ [ править ]

Если после смены репозитория в ответ на команду apt-get update Вы видите сообщение «Unknown vendor ID», то, вероятнее всего, у Вас установлен пакет apt-conf- , отличный от apt-conf-branch. Верните старый репозиторий и установите этот пакет. Вместо обыного «Y» Вам придётся ввести фразу «Yes, do as I say!» (будет подсказка). Либо можно удалить символы [p9] из строк, описывающих новый репозиторий: в этом случае проверка не будет выполняться.

ssh и systemd (screen и т.п.) [ править ]

В конфигурации по умолчанию systemd закрывает всё, что было запущено при входе по ssh. Установите пакет systemd-settings-disable-kill-user-processes: ~~altbug #36633~~

Обновление ExtensionPack для VirtualBox [ править ]

После обновления virtualbox потребуется обновить ExtensionPack. Сделать это можно через меню Файл → Проверить обновления…

Обновление контейнера OpenVZ c хост-системой на p8 [ править ]

p9 содержит glibc 2.27. Этой библиотеке требуется ядро с поддержкой prlimit64, эта поддержка появилась в ядре 3.2.0. В OpenVZ есть механизм для обмана контейнера: в файле /etc/vz/osrelease.conf можно написать, какую версию ядра сообщать в контенер с соответствующим значением переменной OSTEMPLATE. Сверяется начальный набор символов шаблона, полностью значение из OSTEMPLATE можно не писать. Поддержка prlimit64 была бакпортирована в ядро 2.6.32-alt162, проверьте, что в хост-системе установлено ядро не старее этой версии.

Если вы неосторожно обновились без данной подготовки, Вам может помочь «apt-get dedup»: https://lists.altlinux.org/pipermail/sisyphus/2019-September/368152.html

Обновление системы с KDE4 [ править ]

KDE4 в p9 не поддерживается (собственно, и в p8 уже не поддерживается, хотя и работает). Обновление системы с KDE4 может привести к тому, что не запустится графическая подсистема. Удобнее перейти на KDE5 до обновления, чем чинить систему после. Для этого надо установить какой-либо из метапакетов, устанавливающих KDE5: kde5, kde5-big, kde5-maxi, либо какой-то ещё, помеченный как «Set of KDE 5 applications». Пакеты, относящиеся к kde4, потом можно удалить. Например так:

Перед подтверждением исполнения не помешает перепроверить список пакетов к удалению.

Обновление системы с TDE [ править ]

TDE в p9 не поддерживается, следует поступить аналогично случаю с KDE4. Вероятно могут быть проблемы с переносом каких-либо данных, например knotes (не проверено).

Обновление syslog-ng [ править ]

При использовании с journald следует установить пакет syslog-ng-journal: ~~altbug:36454~~.
При обновлении OpenVZ-контейнера с хост-системой на ядре 2.6.32-ovz-el следует скопировать в /etc/syslog-ng/conf.d файл 00-redefine-source-sys.conf из примеров в документации [2] .

Ethernet-мост в etcnet [ править ]

Изменился способ настройки Ethernet-моcта в etcnet.

Сервер виртуализации PVE [ править ]

Прежде чем начинать обновление, необходимо заменить openntpd на chrony (altbug:37656). В противном случае обновление завершится с ошибкой, а при исправлении в ручном режиме придется удалять весь PVE.

Старые профили firefox [ править ]

При запуске со старым профилем из p8 firefox может не запуститься. Если такое случилось, следует «освежить» профиль запуском браузера с ключем —safe-mode (из терминала) и выбрать опцию восстановления «Refresh Firefox». Это исправит профиль с сохранением пользовательских настроек, паролей и истории.

Вход в систему (prefdm) [ править ]

При пользовании systemd после обновления с p8 до p9 может возникнуть необходимость переключиться на применяемый display manager в явном виде:

(либо sddm.service, либо какой иной)

На системах с sysvinit эта проблема не замечена.

Источник

Репозитории ALT Linux

Содержание

Главные правила [ править ]

Подключение репозиториев осуществляется записью соответствующей строки в файл /etc/apt/sources.list, либо в произвольный файл, соответствующий шаблону *.list в каталоге /etc/apt/sources.list.d/. C 2011 года существует утилита apt-repo, которая упрощает манипулирование репозиториями в командной строке. Также подключение и смену репозиториев можно осуществлять посредством графической утилиты Synaptic. Подробнее это описано в статье Управление пакетами, формат строки-источника описан в разделе «Источники репозиториев» этой же статьи.

Дистрибутивы [ править ]

Процесс формирования стабильных веток и дистрибутивов ALT Linux на их основе выглядит так:

в рамках Sisyphus осуществляется текущая разработка (unstable);
когда приходит время очередной стабильной ветки — сизиф притормаживается;
альфа-сборки происходят на «медленном» unstable;
одновременно с фиксацией беты дистрибутива происходит отделение бранча;
далее некоторое время бранч и сизиф идут почти шаг-в-шаг (происходит копирование);
когда в сизифе начинают меняться ABI или иная функциональность, бранч уходит «в автоном»;
дистрибутивы выпускаются на бранче (x.0 и далее x.0.y).

Например, дистрибутивы семейства 8.x выпускаются на базе p8/branch.

До версии 4.1 включительно для дистрибутивов формировались соответвующие опубликованным образам репозитории — например, для ALT Linux Server 4.0 доступен здесь.

Стабильные ветки [ править ]

Каждая стабильная ветка (branch) разработки имеет APT-репозиторий. Поскольку стабильные ветки достаточно консервативны по измененениям, то эти репозитории достаточно безопасны для использования вместе с дистрибутивами (совпадающими по мажорной и минорной цифре в версии). Репозитории стабильных веток можно также использовать для обновления на следующие минорные и мажорные версии.

Для пятой, шестой и седьмой платформ сопровождались сразу две ветви: ветвь для выпуска дистрибутивов (p5, p6, p7) и ветвь сообщества (5.1, t6, t7). Ветвь для выпуска дистрибутивов делает упор на стабильность, надежность и тестирование, а ветвь сообщества отличается более свободным допуском и расширяет ветвь для выпуска дистрибутивов новыми пакетами и новыми версиями имеющихся пакетов, оставаясь в целом бинарно совместимой с ветвью для выпуска дистрибутивов.

Для Восьмой платформы t8 не создавалась, текущие задачи решались в рамках p8. Для Девятой платформы ветка t9 так же не создана.

Существуют также бранчи c* (c6, c7, c8). Это репозитории дистрибутивов, имеющих сертификат ФСТЭК.

Наличие третьего репозитория для x86_64 обусловлено необходимостью поддержки 32-разрядных приложений в 64-разрядной системе. Если такая поддержка не требуется, репозиторий x86_64-i586 тоже не нужен.

Debuginfo [ править ]

Начиная с шестой платформы, появился специфический репозиторий debuginfo. Репозиторий содержит отладочную информацию для бинарных исполняемых файлов и библиотек. Обычным пользователям может быть полезен для формирования отчётов о проблемах в багтрекере. Например, для branch/p7 под x86_64 его можно подключить так:

Autoports [ править ]

Начиная с ветвей p5/5.1 в качестве частичной замены backports появились репозитории Autoports, которые содержат автоматически пересобираемые под текущую стабильную ветвь свежие пакеты из Sisyphus.

Настройка apt для использования Autoports для ветвей p7/t7 описана в Autoports/p7.

Autoimports [ править ]

Пакеты из репозиториев Autoimports отличаются от пакетов в основном репозитории тем, что они получены с помощью систем автоматической конвертации и сборки пакетов и, соответственно, к ним было применено только автоматическое тестирование. Источником для этих репозиториев являются другие дистрибутивы. Перенос заключается в преобразовании spec-файла в соответствии с правилами в ALT Linux и пересборке в соответствующем окружении.

Карманы [ править ]

Это отдельные мини-репозитории сборочницы ALT Linux, то есть задания, которые собраны, но не были отправлены в основной репозиторий. Имеют ограниченное время жизни. Удаляются сборочницей либо после помещения в репозиторий, либо в случае длительной неактивности. Не стоит использовать такие репозитории, если о них не было где-то объявлено (рассылки, форум).

Sisyphus [ править ]

Sisyphus — нестабильный репозиторий, предназначенный для разработчиков решений (приблизительно сравним с Debian testing, Mageia Cauldron, Fedora Rawhide в других проектах), а не для пользователей. Как правило, до репозитория Sisyphus можно обновить любую достаточно свежую ОС семейства ALT, но при наличии целенаправленной задачи использования Sisyphus для начальной установки лучше всего подходят регулярные сборки.

Зеркала [ править ]

Также существуют зеркала репозиториев.

Вот пример зеркала на яндексе для ветки p8 под 64-битный x86:

Устаревшие репозитории [ править ]

Updates [ править ]

Для каждой стабильной ветки и дистрибутивов вплоть до 4.1 существовали обновления (updates), содержащие критичные исправления по безопасности и функционалу. Обратите внимание: в updates отсутствуют отдельные репозитории для noarch-пакетов: noarch-пакеты включены в архитектурно-зависимые репозитории.

В настоящее время в качестве Updates используются стабильные ветви.

Для дистрибутивов, выпущенных на ветке 4.0:

Backports [ править ]

Для каждой стабильной ветки вплоть до 4.1 существовали backports: репозитории, в которые майнтайнеры переносят (пересобирают) более свежие пакеты, которые нельзя переложить в сами ветки из-за политики подготовки веток. Эта работа производится и тестируется вручную и в последнее время практически заглохла.

В настоящее время вместо backports используются Autoports и ветви, сопровождаемые Team (branch/5.1, branch/t6).

branch/4.1 (на данный момент — только для x86)

Источник