Linux как добавить репозиторий alt linux

Обновлено: 04.07.2024

Процесс формирования стабильных веток и дистрибутивов 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). Ветвь для выпуска дистрибутивов делает упор на стабильность, надежность и тестирование, а ветвь сообщества отличается более свободным допуском и расширяет ветвь для выпуска дистрибутивов новыми пакетами и новыми версиями имеющихся пакетов, оставаясь в целом бинарно совместимой с ветвью для выпуска дистрибутивов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одной из наиболее важных задач – обеспечение жизненного цикла продуктов, для чего необходимо создание удобной и эффективной среды для разработки. «Базальт СПО» постоянно совершенствует среду для сборки, делая ее максимально комфортной и современной. Сейчас это легко разворачиваемая сборочная среда, не требующая отдельного сервера и обеспечивающая полностью изолированную сборку из произвольного хранилища ALT.

Основа всех дистрибутивов Альт — репозиторий Sisyphus, который стал одним из крупнейших в мире банков пакетов свободных программ с поддерживаемой целостностью. Он основан на уникальных технологиях сборки с собственной дисциплиной оформления компонентов. Благодаря сохраняемой истории изменений исходных текстов и жесткому контролю приемки готовых пакетов программ практически исключается вероятность возникновения критических ошибок, влекущих за собой всевозможные сбои в сборках образов и появление нерабочих компонентов в них.

Ключевыми решениями в удобном оформлении программных компонентов являются средство управления пакетами RPM и высокоуровневый диспетчер APT. В их основе лежит ряд взаимосвязанных технологий, обеспечивающих максимальную автоматизацию при работе: поиск зависимостей, создание спецификаций и т.д.

Все это создает отличную базу для выпуска широкого спектра дистрибутивов различной направленности. В настоящее время «Базальт СПО» поддерживает целую линейку своих дистрибутивов. Процесс создания образа дистрибутива также максимально автоматизирован благодаря отечественным технологиям создания профилей, которые формируют набор пакетов из репозитория для конкретного дистрибутива, сохраняя при этом целостность и работоспособность системы.

Восьмая платформа (p8) — стабильная инфраструктура репозитория пакетов свободных программ, предназначенная для разработки, тестирования, распространения, обновления и поддержки комплексных решений, созданной и развиваемой в рамках проекта Sisyphus командой ALT Linux Team.

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

Для быстрого начала работы с Восьмой платформой «Базальт СПО» предлагает пользователям, предпочитающим самостоятельно определять состав и оформление системы, загрузочные образы комплектов входа (starter kits) для архитектур i586 и x86_64 в более чем десяти вариантах окружений рабочего стола и нескольких вариантах для серверов, облачных решений и задач администрирования системы.

На основе Восьмой платформы выпущены дистрибутивы: Альт Рабочая станция, Альт Сервер, Альт Образование, Simply Linux.

1 — настроить выкачку официального репозитория

Поиски решения первой части задачи навели на статью Дмитрия Коновалова. Второй способ из этой статьи (воспользоваться утилитой alterator-mirror) подходило мне больше всего, но оно особо не раскрывается

Поэтому для начала устанавливаем утилиту alterator-mirror

Установка программы Alterator-mirror

запускаем synaptic (меню К -настройка-Программа управления пакетами Synaptic)

нажимаем «Искать», в поле поиска вводим alterator-mirror (по умолчанию пакет не установлен)

устанавливаем данную утилиту

Настройка хранилища репозитория

Второй важный шаг — настроить хранилище репозитория. Размер репозитория может быть очень значительным, поэтому рекомендуется изменить место сохранения репозитория (переполнение корневого каталога приведет к сбою в работе ОС). Я создал еще один раздел, на котором и буду хранить репозиторий. Это сделал по одной причине: если система рухнет, то я скорее всего не буду восстанавливать ее, а удалю все диски с системой и затем переставлю систему, но диск с репозиторием у меня сохранится и мне заново репозиторий не придется скачивать. Если кто-то желает воспользоваться моим советом, то первым делом следует создать новый локальный диск желательно с файловой системой ОС Линукс (я взял ext3, размер диска выбрал 15 гб). Важно: для локального диска следует выбрать линуксовую файловую систему (ext2, ext3. ) (связано с настройками фтп-сервера). На этом диске создал папку localrep, для хранения локального репозитория.

Возникла проблема в том, что после запуска компьютера данный диск автоматически не монтировался. Данная проблема была решена после прописания в файле /etc/fstab строки

/dev/hda8 /media/disk ext3 nosuid,auto 0 0

У вас может быть и не hda8, а какой-то другой. Посмотреть можно через свойства папки в обозревателе. Важно без ошибочно написать эту строку. Лишние пробелы недопустимы. В конце строки следует нажать enter. Можно уже при установке Ос Линукс при создании разделов создать еще один раздел и в качестве точки монтирования указать /srv/public.

/media/disk/localrep /srv/public/mirror none rw,bind,auto 0 0

где /media/disk/localrep — папка-хранилище локального репозитория.

Настройка сервера обновлений

В поле логин вводим root

Во вкладке серверы выбираем серверы обновлений, настраиваем время автоматического зеркалирования

Выбираем репозиторий который будем зеркалировать, например, «Стабильная ветка ALT Linux 5.0»

И все. Теперь репозиторий будет сохраняться в папку localrep. Осталось настроить ftp-сервер на работу с этой папкой и в synaptic в качестве репозитория указать параметры ftp-сервера. Размер репозитория у меня составил 6.5 гб. Теперь я могу репозиторий раздавать по школам (копируя на флэшку или жесткий диск). Обновление репозитория практически не использует трафик, поэтому школы могут спокойно сами обновлять репозиторий.

Итак, подводя итог вышенаписанному, хочется сказать, что создание локального репозитория позволит обновлять ОС Линукс, экономя при этом трафик.

В следующей статье я расскажу как настроить ftp-сервер для раздачи репозитория.

Подключение репозиториев осуществляется записью соответствующей строки в файл /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.

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

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

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

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

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

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

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

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

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

В современных системах на базе 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.

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

Post by ИМХО » 26 Jun 2010, 11:19

Создание локального репозитория

Для создания репозитория достаточно создать правильную структуру директорий, разместить в ней rpm-пакеты и создать метаинформацию для APT.

Структура APT-RPM репозитория
APT-RPM репозиторий выглядит достаточно просто:

Такая структура формирует три источника для APT (<base directory> - место, где располагается репозиторий):

NB: указываем noarch и один из архитектурно-зависимых репозиториев, всё в кучу не надо!
Более изощрённую структуру директорий, когда в репозитории хранятся пакеты с иходным текстом (.src.rpm), общие для нескольких архитектур, а также когда в репозитории имеется несколько компонентов (в данном репозитории компонент один - reponame), можно посмотреть, к примеру, в репозитории ALT Linux Server. Обратите внимание, что в этом репозитории используется отдельная директория files для хранения всех пакетов, и директории RPMS.*/SRPMS.* являются символическими ссылками на поддиректории из files.

Размещение пакетов

Просто разложите пакеты по директориям /RPMS.reponame в зависимости от архитектуры пакета.
Создание/обновление метаинформации

Для создания/обновления метаинформации (файлов, хранящихся в директории base), используйте утилиту genbasedir из пакета apt-repo-tools (до 5.0/branch включительно -- apt-utils):

Полезные советы

Создание «скелета» репозитория

Добавление произвольного набора пакетов в репозиторий
Перед запуском этого скрипта, возможно нужно будет установить недостающие пакеты:

Вот скрипт для добавления пакетов: Файл:Addpackages.sh

После этой операции необходимо обновить метаинформацию. Побочным эффектом является приведение имён файлов с пакетами к «каноническому» виду.
Создание репозитория на основе содержимого кэша APT
Добавьте содержимое кэша APT в репозиторий (см. выше) и обновите метаинформацию (см. выше).
втоматизация добавления пакетов в репозиторий
Воспользуйтесь скриптами из пакета sisyphus.

Читайте также: