- Arch Build System (Русский)
- Contents
- Обзор
- Дерево репозитория
- Способы применения
- Использование
- Получение PKGBUILD
- PKGBUILD из Git
- PKGBUILD из SVN
- Сборка пакета
- Советы и рекомендации
- Сохранение изменённых пакетов
- Official repositories (Русский)
- Contents
- Стабильные репозитории
- extra
- community
- multilib
- Включение multilib
- Отключение multilib
- Тестовые репозитории
- testing
- community-testing
- multilib-testing
- gnome-unstable
- kde-unstable
- Отключение тестовых репозиториев
- Репозитории Staging
- Историческая справка
Arch Build System (Русский)
Система сборки Arch (Arch Build System, ABS) — схожая с портами система сборки программных пакетов из исходного кода. В отличие от pacman, который является инструментом управления двоичными пакетами (в том числе собранными с помощью ABS), система сборки Arch — набор утилит для компилирования исходников в устанавливаемый (.pkg.tar.zst) пакет.
Порты используются в ОС семейства BSD для автоматизации процесса сборки программ из файлов с исходным кодом. Порты помогают загружать, распаковывать, патчить, компилировать и устанавливать программы. Сам по себе порт является небольшой директорией на компьютере пользователя, название которой совпадает с названием устанавливаемой программы. Данная директория содержит файлы с инструкциями по установке и сборке программ. Благодаря этому установка сильно упрощается: как правило, необходимо лишь выполнить команду make или make install clean в директории порта.
Концепция ABS во многом похожа. Частью системы сборки является SVN-репозиторий и эквивалентный ему Git-репозиторий. Репозиторий состоит из каталогов, каждый из которых предназначен для отдельного пакета Arch Linux. В директориях содержатся файлы PKGBUILD (и иногда некоторые другие файлы), но в них нет ни исходников, ни двоичных файлов программ. Если выполнить команду makepkg внутри директории, то исходники программы будут загружены, скомпилированы и собраны в пакет. После этого можно воспользоваться pacman, чтобы установить данный пакет в систему.
Contents
Обзор
Система сборки Arch часто используется как обобщённый термин для целого ряда компонентов, хоть это и не совсем правильно. Обычно под ABS понимают следующие инструменты:
Дерево репозитория Набор каталогов, в которых хранятся необходимые для сборки всех официальных пакетов файлы — но не сами пакеты и не файлы с исходным кодом. Доступны две версии репозитория, svn и git. Подробнее см. раздел #Дерево репозитория. PKGBUILD Bash-скрипт, в котором находится URL для скачивания файлов с исходным кодом, а также инструкции по их компиляции в двоичный код и упаковке. makepkg Утилита командной строки, которая читает PKGBUILD, автоматически скачивает файлы с исходным кодом, компилирует их и создает пакет .pkg.tar* (какой конкретно суффикс будет у пакета определяется параметром PKGEXT в файле makepkg.conf ). makepkg также можно использовать для создания пакетов из AUR или сторонних источников, подробнее см. Создание пакетов. pacman pacman является полностью отдельным проектом, но он вызывается (утилитой makepkg или вручную) каждый раз при установке или удалении собранных пакетов, а также для установки зависимостей. AUR Пользовательский репозиторий Arch (Arch User Repository, AUR) — отдельное от ABS хранилище файлов PKGBUILD для программ, не вошедших в официальные репозитории. В отличие от дерева ABS, которое представляет собой «голый» репозиторий git, у AUR есть интерактивный веб-интерфейс. В AUR находятся тысячи предложенных пользователями файлов PKGBUILD для программ, которые не имеют официального пакета Arch. Если вам нужен пакет, которого нет в официальных репозиториях, стоит поискать его в AUR.
Дерево репозитория
В SVN-репозитории packages хранятся файлы PKGBUILD пакетов из официальных репозиториев core, extra и testing, а в SVN-репозитории community — файлы из community и multilib.
В SVN-репозитории для каждого пакета выделен отдельный каталог, в котором находятся подкаталоги repos и trunk . В repos , в свою очередь, есть ещё один каталог, имя которого состоит из названия официального репозитория пакета (например, core) и архитектуры процессора. Файлы PKGBUILD, которые находятся в repos , используются в качестве официальной сборки. Файлы в trunk используются разработчиками до перемещения в repos .
Например, дерево каталогов для acl выглядит следующим образом:
Исходного кода пакета в SVN-репозитории нет. Вместо этого файл PKGBUILD содержит URL официального репозитория, из которого исходный код будет загружен во время сборки.
Способы применения
ABS позволяет автоматизировать некоторые задачи, связанные с компиляцией из исходников. Например:
- Компиляция или перекомпиляция пакета;
- Сборка из исходных кодов и установка программ, для которых ещё нет официального пакета (см. Создание пакетов);
- Изменение существующих пакетов под свои нужды (включение или отключение опций, внесение исправлений);
- Перестройка всей системы с использованием новых флагов компиляции «à la FreeBSD»;
- Чистая сборка и установка собственного ядра (см. Ядро#Компиляция);
- Создание модулей для вашего собственного ядра;
- Компиляция и установка новой/старой/beta/devel версии Arch-пакета с помощью редактирования номера версии в PKGBUILD.
Использование
Получение PKGBUILD
Существует два способа добыть необходимый для сборки конкретного пакета из исходников файл PKGBUILD: либо посредством SVN, либо через Git программой asp , которая представляет собой обёртку для svntogit-репозиториев. Ниже рассматриваются оба подхода.
PKGBUILD из Git
Установите пакет asp . Asp — инструмент для скачивания исходных файлов пакетов Arch Linux через Git-интерфейс. Подробнее см. обсуждение на форуме.
Чтобы выполнить «сверку» (checkout) пакета из репозитория, выполните:
Пакет будет клонирован в каталог, имя которого совпадает с названием пакета. Для обновления клонированного git-репозитория необходимо перейти в него и последовательно выполнить команды asp update и git pull .
Кроме того, можно использовать другие команды git для сверки более старых версий пакета и отслеживания изменений. Подробнее см. Git.
Если необходимо просто получить копию снимка (snapshot) текущего PKGBUILD для конкретного пакета, выполните:
PKGBUILD из SVN
Предварительные условия
Сверка репозитория
Соответствующая команда для репозиториев community и multilib:
В обоих случаях единственным видимым результатом будет создание пустого каталога.
Сверка пакета
Перейдите в созданный каталог, packages или community, и выполните:
Эта команда выполнит сверку указанного пакета. С этого момента каждый раз при выполнении svn update будет происходить его обновление.
Если запрошенный пакет не существует, svn не выдаст предупреждение. В терминале появится только что-то вроде «At revision 358704» без создания каких-либо файлов. Если это произошло:
- проверьте правильность имени пакета;
- проверьте, не был ли пакет перемещен в другой репозиторий (например, из community в packages);
- проверьте страницу https://archlinux.org/packages чтобы убедиться, что ваш пакет не собирается на основе другого пакета (например, python-tensorflow собирается по PKGBUILD пакета tensorflow ).
Все синхронизированные пакеты можно периодически обновлять, если вы желаете пересобирать актуальные версии пакетов из репозиториев. Для этого выполните:
Сверка старой версии пакета
Находясь в сверенном svn-репозитории (т.е. packages или community, как описано в разделе #Сверка репозитория), сначала изучите лог:
Найдите ревизию, которая вам нужна, и укажите её номер в команде синхронизации. Например, чтобы синхронизировать ревизию r1729 , выполните:
Выбранный пакет обновится до нужной версии.
Вместо номера ревизии можно указать дату. Если на эту дату нет ревизии, то svn найдет ближайшую ревизию перед ней. Пример (для даты 2009-03-03):
Это даёт возможность синхронизации пакета с последней версией до перемещения в другой репозиторий. Необходимо лишь найти в логах дату перемещения или же последний номер ревизии.
Сборка пакета
Перед сборкой пакета из файла PKGBUILD настройте makepkg в соответствии с указаниями из раздела makepkg#Настройка.
Скопируйте каталог с файлом PKGBUILD в другое место, отредактируйте его, если необходимо, после чего соберите пакет и установите его в систему, как описано в разделе makepkg#Использование.
Советы и рекомендации
Сохранение изменённых пакетов
При первом же обновлении системы pacman заменит модифицированный вами пакет из ABS на стандартный пакет с таким же названием из официальных репозиториев. Ниже описано, как этого не допустить.
Добавьте параметр groups в PKGBUILD пакета и укажите в нём группу modified .
Добавьте эту группу в раздел IgnoreGroup файла /etc/pacman.conf .
Если в официальных репозиториях появится новая версия этого пакета, то во время обновления системы pacman напечатает замечание, что он пропускает пакет, поскольку тот находится в разделе IgnoreGroup . После этого необходимо вручную пересобрать новую версию пакета из ABS, чтобы ваша система не оказалась «частично обновлённой».
Источник
Official repositories (Русский)
Репозиторий — хранилище пакетов программ, которые можно загрузить и установить на компьютер.
Официальные репозитории Arch Linux содержат наиболее важное и популярное программное обеспечение, которое можно легко получить и установить при помощи pacman. Эти репозитории поддерживают мейнтейнеры пакетов.
Пакеты в официальных репозиториях постоянно обновляются, при этом старые версии пакетов сразу удаляются. В Arch нет главных (major) релизов дистрибутива: каждый пакет обновляется сразу после того, как его новая версия становится доступна в upstream. Каждый репозиторий полноценен в том смысле, что содержит в себе совместимые между собой версии программ.
Contents
Стабильные репозитории
Этот репозиторий можно найти в каталоге . /core/os/ на каждом из доступных зеркал.
core содержит пакеты для:
- Загрузки Arch Linux
- Подключения к интернету
- Сборки пакетов
- Управления и восстановления поддерживаемых файловых систем
- Процесса установки системы (например, openssh )
а также все необходимые зависимости этих пакетов (необязательно из makedepends) и мета-пакета base .
core имеет достаточно строгие требования к качеству. Разработчики/пользователи должны подтвердить (в ответ на signoff-запрос в почтовой рассылке) работоспособность обновлений, прежде чем они будут приняты. Для малоиспользуемых пакетов обычно достаточно следующих шагов: информирование пользователей об обновлении, запрос подтверждений, удержание пакета в #testing около недели (в зависимости от серьёзности изменений), отсутствие серьёзных баг-репортов и неявное подтверждение от мейнтейнера пакета.
extra
Этот репозиторий можно найти в каталоге . /extra/os/ на каждом из доступных зеркал.
extra содержит все пакеты, которые не подходят для core. Например: Xorg, оконные менеджеры, веб-браузеры, медиаплееры, инструменты для работы с языками, такими как Python и Ruby, и многое другое.
community
Этот репозиторий можно найти в каталоге . /community/os/ на каждом из доступных зеркал.
community содержит пакеты из AUR, принятые доверенными пользователями. Некоторые из этих пакетов в конечном итоге могут оказаться в репозиториях core или extra, если разработчики посчитают их важными для дистрибутива.
multilib
Этот репозиторий можно найти в каталоге . /multilib/os/ на каждом из доступных зеркал.
multilib содержит 32-битное программное обеспечение и библиотеки, которые можно использовать для запуска и сборки 32-битных приложений на 64-битных системах (например, wine , steam и т.д.).
32-битные библиотеки хранятся в директории /usr/lib32/ при включённом репозитории multilib.
Включение multilib
Раскомментируйте раздел [multilib] в /etc/pacman.conf , чтобы включить репозиторий multilib:
Затем обновите систему и установите необходимые multilib-пакеты.
Отключение multilib
Выполните следующую команду, чтобы удалить все пакеты, установленные из репозитория multilib:
Если вы столкнулись с конфликтами с gcc-libs, переустановите пакет gcc-libs и группу base-devel .
Закомментируйте раздел [multilib] в /etc/pacman.conf :
Тестовые репозитории
Тестовые репозитории предоставляют площадку для размещения пакетов перед принятием их в основные репозитории. Сопровождающие пакетов (и широкая аудитория) могут получить доступ к тестовым пакетам, чтобы убедиться в отсутствии проблем при работе с новой версией приложения. Пакет может быть перемещён в основные репозитории, как только он был протестирован и ошибок не было обнаружено.
Требование тестирования пакетов в таких репозиториях обязательно только для пакетов из репозитория core и пакетов, затрагивающих множество других программ (например, perl и python ), а также обычно применимо к большим коллекциям ПО, например, GNOME или KDE.
testing
Этот репозиторий можно найти в каталоге . /testing/os/ на каждом из доступных зеркал.
testing содержит пакеты, являющиеся кандидатами на внесение в репозитории core и extra.
Новые пакеты попадают в testing в следующих случаях:
- Они предназначены для репозитория core. Все пакеты для core сперва должны пройти через testing.
- Есть вероятность того, что они повредят что-либо при обновлении, в следствие чего их необходимо сперва протестировать.
testing — единственный репозиторий, в котором могут быть совпадения имён с другими официальными репозиториями. Если он включён, он должен быть первым репозиторием среди перечисленных в файле /etc/pacman.conf .
community-testing
Этот репозиторий похож на репозиторий testing, но создан для пакетов, являющихся кандидатами на внесение в репозиторий community.
multilib-testing
Этот репозиторий похож на репозиторий testing, но создан для пакетов, являющихся кандидатами на внесение в репозиторий multilib.
gnome-unstable
Этот репозиторий содержит пакеты с будущим релизом (или кандидатом в релиз) окружения рабочего стола GNOME до их перевода в главный репозиторий testing.
Добавьте нижеприведенные строки в файл /etc/pacman.conf , чтобы включить данный репозиторий:
Репозиторий gnome-unstable должен быть первым в списке репозиториев (в том числе выше записи для репозитория testing).
Информацию об относящихся к упаковке багах сообщайте в нашу систему отслеживания ошибок, прочая информация должна направляться непосредственно разработчикам на GNOME Gitlab.
kde-unstable
Этот репозиторий содержит самую свежую бета-версию или версию-кандидат на выпуск KDE Plasma и Applications.
Добавьте нижеприведенные строки в файл /etc/pacman.conf , чтобы включить данный репозиторий:
Репозиторий kde-unstable должен быть первым в списке репозиториев (в том числе выше записи для репозитория testing).
Отключение тестовых репозиториев
Если вы ранее включили тестовые репозитории, а теперь решили их отключить, необходимо:
- Удалить (закомментировать) их из файла /etc/pacman.conf .
- Выполнить pacman -Syuu , чтобы «откатить» обновления из этих репозиториев.
Второй пункт необязателен, но помните об этом на случай, если вы заметите какие-либо проблемы.
Репозитории Staging
Данные репозитории содержат нерабочие пакеты и используются исключительно разработчиками во время одновременной пересборки большого количества пакетов. Чтобы пересобрать пакет, зависящий, например, от новой разделяемой библиотеки, необходимо сначала собрать саму библиотеку и загрузить её в staging-репозиторий — таким образом она будет доступна другим разработчикам. После пересборки всех зависимых пакетов эту группу перемещают в тестовые или основные репозитории (в зависимости от случая).
См. [1] для получения информации об исторических деталях.
Историческая справка
Разделение репозиториев появилось по историческим причинам. Когда дистрибутивом не пользовалось много людей, был только один репозиторий, известный как official (нынешний core). В то время official содержал в основном приложения, которые предпочитал Джадд Винет (Judd Vinet — основатель Arch Linux). Репозиторий был устроен таким образом, чтобы содержать «всего по одному»: одно окружение рабочего стола, один основной браузер и т.д.
Конечно, были пользователи, которым не нравился выбор Джадда, и, когда появилась удобная система сборки пакетов, они начали создавать собственные пакеты. Эти пакеты вошли в репозиторий unofficial и поддерживали их другие разработчики, а не Джадд. В конце концов, разработчиками было принято решение поддерживать оба репозитория, и названия official и unofficial перестали отображать их истинный смысл. Примерно в районе версии 0.5 названия были изменены на current и extra.
Вскоре после выхода версии 2007.8.1, current был переименован в core, чтобы не было неоднозначностей в трактовке того, что, собственно, должен содержать репозиторий. Сейчас репозитории практически равны в глазах разработчиков и сообщества, но core имеет некоторые отличия. Самое главное из них — то, что только пакеты из core включаются в установочные CD и релизы. Этот репозиторий все ещё содержит полноценную систему Linux, однако, скорее всего, это не та система, которую вы хотели бы использовать.
Примерно между версиями 0.5 и 0.6 обнаружилось, что есть большое количество пакетов, которые разработчики не хотели поддерживать. Джейсон Чу (Jason Chu) создал неофициальные «Репозитории Доверенных Пользователей» (Trusted User Repositories), где доверенные пользователи могли размещать созданные ими пакеты. Также существовал репозиторий staging, из которого пакеты могли быть перенесены в официальные репозитории одним из разработчиков Arch Linux, но, если не считать этого пункта, разработчики и доверенные пользователи были практически равны.
Такое разделение работало до тех пор, пока доверенным пользователям не надоело поддерживать собственные репозитории, а обычные пользователи не захотели выкладывать свои пакеты. Это привело к развитию AUR. Доверенные пользователи объединились в меньшую по размеру группу, которая сейчас поддерживает репозиторий community. Доверенные пользователи все ещё образуют отдельную от разработчиков Arch Linux группу и довольно мало общаются между собой. Тем не менее, популярные пакеты время от времени все ещё перемещают из community в extra. AUR позволяет также обычным пользователям выкладывать свои файлы PKGBUILD.
После того, как однажды ядро из репозитория core поломало множество систем, в репозитории была введена политика подтверждения («core signoff policy»). С тех пор все обновления пакетов для core должны сперва пройти через репозиторий testing и только после нескольких подтверждений («signoffs») от других разработчиков пакет можно перенести. Через какое-то время было замечено, что некоторые пакеты в core почти не используются, а число подписей пользователей и отсутствие отчётов об ошибках неофициально стали критерием для утверждения таких пакетов.
В конце 2009 и начале 2010, в связи с созданием новых файловых систем и желанием поддерживать их при установке, а также осознанием того, что репозиторий core никогда не был чётко структурирован (просто «важные пакеты, выбранные разработчиками»), назначение репозитория было сформулировано более точно.
Источник