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

APT в ALT Linux/CreateRepository

Содержание

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

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

Структура APT-RPM репозитория [ править ]

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

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

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.

Запись репозитория на CD/DVD [ править ]

rpm-dir [ править ]

Можно создать репозиторий в виде одного каталога без всяких индексов.

1. Создайте два вложенных каталога:

2. Скопируйте все файлы (например, все файлы *.rpm из /var/cache/apt/archives/ , которые устанавливались вручную или через обновления системы). Делать это нужно под root!

3. На машине, где нужны эти обновления, пропишите репозиторий:

rpm-dir используется в случае, когда в репозитории нет каталога base с индексом пакетов. Его удобно использовать, например, для подключения репозитория с несколькими свежесобранными пакетами. Так делает hasher в режиме по умолчанию (—with-stuff). Однако в этом случае apt-get update будет открывать каждый пакет в репозитории, для большого набора (в частности, для зеркала) такой способ не годится.

Источник

Репозитории 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)

Источник

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.

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

Источник

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.

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

Источник