Creating a pkgbuild to make packages for arch linux

Обзор

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

Дерево репозитория

PKGBUILD: Bash-скрипт, в котором находится URL для скачивания файлов с исходным кодом, а также инструкции по их компиляции в двоичный код и упаковке.

makepkg: Утилита командной строки, которая читает PKGBUILD, автоматически скачивает файлы с исходным кодом, компилирует их и создает пакет .pkg.tar* (какой конкретно суффикс будет у пакета определяется параметром в файле ). makepkg также можно использовать для создания пакетов из AUR или сторонних источников, подробнее см. Создание пакетов.

pacman: pacman является полностью отдельным проектом, но он вызывается (утилитой makepkg или вручную) каждый раз при установке или удалении собранных пакетов, а также для установки зависимостей.

AUR: Пользовательский репозиторий Arch (Arch User Repository, AUR) — отдельное от ABS хранилище файлов PKGBUILD для программ, не вошедших в официальные репозитории. В отличие от дерева ABS, которое представляет собой «голый» репозиторий git, у AUR есть интерактивный веб-интерфейс. В AUR находятся тысячи предложенных пользователями файлов PKGBUILD для программ, которые не имеют официального пакета Arch. Если вам нужен пакет, которого нет в официальных репозиториях, стоит поискать его в AUR.

Важно: Официальные файлы PKGBUILD разрабатываются исходя из предположения, что пакеты будут собираться в чистом chroot-окружении. Грязная cборка может привести к непредсказуемому поведению программы во время исполнения

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

Дерево репозитория

В SVN-репозитории packages хранятся файлы PKGBUILD пакетов из официальных репозиториев core, extra и testing, а в SVN-репозитории community — файлы из community и multilib.

В SVN-репозитории для каждого пакета выделен отдельный каталог, в котором находятся подкаталоги и . В , в свою очередь, есть ещё один каталог, имя которого состоит из названия официального репозитория пакета (например, core) и архитектуры процессора. Файлы PKGBUILD, которые находятся в , используются в качестве официальной сборки. Файлы в используются разработчиками до перемещения в .

Например, дерево каталогов для выглядит следующим образом:

acl
acl/repos
acl/repos/core-x86_64
acl/repos/core-x86_64/PKGBUILD
acl/trunk
acl/trunk/PKGBUILD

Исходного кода пакета в SVN-репозитории нет. Вместо этого файл PKGBUILD содержит URL официального репозитория, из которого исходный код будет загружен во время сборки.

Использование

Для корректной работы makepkg нужно установить группу пакетов . Пакеты из этой группы можно не указывать в качестве зависимостей для сборки (makedepends) в файле PKGBUILD.

Примечание:

Убедитесь, что утилита sudo настроена должным образом для команд, передаваемых pacman.

Чтобы собрать пакет, первым делом необходимо создать файл PKGBUILD, который представляет собой скрипт сборки. Написание скрипта описано в статье Создание пакетов. Скрипты для существующих пакетов можно найти в дереве каталогов Системы сборки Arch, а также в AUR. После того, как получен, переместитесь в каталог с ним и выполните команду сборки пакета:

$ makepkg

Если в системе не установлены необходимые зависимости, makepkg предупредит вас об этом и отменит сборку. Если задать флаг /, то makepkg самостоятельно установит недостающие зависимости и соберёт пакет.

$ makepkg --syncdeps

С флагом / makepkg после сборки удалит те зависимости, которые будут больше не нужны. Если вы постоянно занимаетесь сборкой пакетов и не хотите загрязнять систему пакетами-сиротами, то стоит также ознакомиться со статьёй .

Примечание:

Устанавливаемые пакеты-зависимости должны находиться в подключённых репозиториях; в статье описана настройка репозиториев. Кроме того, зависимости можно установить вручную командой .
При установке зависимостей используются только глобальные значения переменных, то есть переопределить значения, например, внутри функции упаковки разделённого пакета (split package) не получится.

Когда все зависимости установлены и сборка пакета завершилась успешно, в рабочем каталоге появится файл пакета (). Чтобы установить его в систему, используйте флаг / (работает аналогично команде ):

$ makepkg --install

С флагом / makepkg удалит оставшиеся после сборки промежуточные файлы и каталоги (например, распакованные в файлы). Это полезно при многократных сборках одного и того же пакета или его обновления в одном рабочем каталоге. Это предотвратит добавление устаревших файлов в новые сборки:

$ makepkg --clean

Подробнее см. .

Testing the PKGBUILD and package

As you are writing the function, you will want to test your changes frequently to ensure there are no bugs. You can do this using the command in the directory containing the file. With a properly formatted , makepkg will create a package; with a broken or unfinished , it will raise an error.

If makepkg finishes successfully, it will place a file named in your working directory. This package can be installed with the command. However, just because a package file was built does not imply that it is fully functional. It might conceivably contain only the directory and no files whatsoever if, for example, a prefix was specified improperly. You can use pacman’s query functions to display a list of files contained in the package and the dependencies it requires with and respectively.

If the package looks sane, then you are done! However, if you plan on releasing the file, it is imperative that you check and double-check the contents of the array.

Also ensure that the package binaries actually run flawlessly! It is annoying to release a package that contains all necessary files, but crashes because of some obscure configuration option that does not quite work well with the rest of the system. If you are only going to compile packages for your own system, though, you do not need to worry too much about this quality assurance step, as you are the only person suffering from mistakes, after all.

Checking package sanity

After testing package functionality check it for errors using namcap:

$ namcap PKGBUILD
$ namcap <package file name>.pkg.tar.zst

Namcap will:

Check PKGBUILD contents for common errors and package file hierarchy for unnecessary/misplaced files
Scan all ELF files in package using , automatically reporting which packages with required shared libraries are missing from and which can be omitted as transitive dependencies
Heuristically search for missing and redundant dependencies

and much more.

Get into the habit of checking your packages with namcap to avoid having to fix the simplest mistakes after package submission.

История

В начале времён был лишь FTP-сервер , на который люди загружали свои файлы PKGBUILD, другие необходимые файлы и сами собранные пакеты. Пакет и связанные с ним файлы хранились на сервере, ожидая проверки и добавления в официальный репозиторий.

Позднее некоторым участникам сообщества было разрешено содержать собственные репозитории с общим доступом. Так появились репозитории доверенных пользователей (Trusted User Repositories). AUR был создан как развитие этой идеи, чтобы сделать систему более гибкой и удобной. AUR-мэйнтейнеры до сих пор часто упоминаются как доверенные пользователи (Trusted Users, TU).

Между 2015-06-08 и 2015-08-08 состоялся переход AUR с версии 3.5.1 на 4.0.0, что было связано с началом использования Git-репозиториев для публикации файлов . Существовавшие на тот момент пакеты были частично перенесены в новую инфраструктуру их сопроводителями.

Configuration

See for details on configuration options for makepkg.

The system configuration is available in , but user-specific changes can be made in or . It is recommended to review the configuration prior to building packages.

Packager information

Each package is tagged with metadata identifying amongst others also the packager. By default, user-compiled packages are marked with . If multiple users will be compiling packages on a system, or if one is otherwise distributing packages to other users, it is convenient to provide real contact. This can be done by setting the variable in .

To check this on an installed package:

$ pacman -Qi package

...
Packager       : John Doe <john@doe.com>
...

To automatically produce signed packages, also set the variable in .

Package output

By default, makepkg creates the package tarballs in the working directory and downloads source data directly to the directory. Custom paths can be configured, for example to keep all built packages in and all sources in .

Configure the following variables if needed:

— directory for storing resulting packages
— directory for storing data (symbolic links will be placed to if it points elsewhere)
— directory for storing resulting source packages (built with )

Tip: The directory can be cleaned up with e.g. as described in .

Signature checking

If a signature file in the form of .sig or .asc is part of the PKGBUILD source array, makepkg automatically attempts to it. In case the user’s keyring does not contain the needed public key for signature verification, makepkg will abort the installation with a message that the PGP key could not be verified.

If a needed public key for a package is missing, the PKGBUILD will most likely contain a entry with the required key IDs. it manually, or find it and import it from there.

Использование Dropbox

Теперь, когда на вашем ПК с Linux включен пакет Dropbox, пора все настроить. Когда вы запустите его, вам будет предложено войти в сервис Dropbox. Используйте окно входа в систему, чтобы войти в свою учетную запись. Кроме того, если у вас нет учетной записи, вам нужно сначала создать ее на Dropbox.com.

После входа в систему приложение Dropbox сообщит вам, что ему необходимо загрузить проприетарный двоичный файл Dropbox. Нажмите «ОК» и позвольте ему загрузить его. Когда двоичный файл работает, приложение синхронизации Dropbox должно быть полностью функциональным и готовым к работе.

По умолчанию Dropbox автоматически начнет скачивать все элементы, привязанные к вашей учетной записи. Если вы хотите выполнить выборочную синхронизацию, нажмите кнопку «Выборочная синхронизация» в приложении Dropbox, а затем установите (или снимите флажок) с папок и файлов.

Именно в этот момент вы сможете начать процесс синхронизации. Откройте окно файлового менеджера и поместите в него элементы, которые вы хотите синхронизировать. / главная / имя пользователя / Dropbox. Они должны немедленно начать загрузку.

Загрузка пакета в AUR

Никаких . С недавних пор данный метод считается устаревшим. Но
обо всем по-порядку

Нам нужно загрузить архив на сайт. В этом архиве должны быть PKGBUILD и
.AURINFO. По поводу первого я расскажу еще чуть ниже, второй генерируется
автоматически. Также, там могут быть установочные скрипты (*.install), патчи,
файлы лицензии (если не предоставляются апстримом с исходниками), сервисы
systemd, скрипты запуска — это то, что обычно включено. Никаких исходников.
И тем более никаких бинарников. (Шутки-шутками, а я помню пакет, в котором
исходный код записывался с помощью прямо в тексте PKGBUILD’а.)

Все файлы кладем в одну директорию. Убедились, что install файл, если он есть,
указан в переменной install, все другие исходные файлы указаны в массиве source,
а хэш-суммы правильные (их легко можно сгенерировать, набрав ).
Далее из этой директории запустить команду (пакет
pkgbuild-introspection) — и архив готов.

Несколько правил загрузки пакета в AUR:

Если такой пакет существует в официальном репозитории (любой версии), то не
нужно заливать новый пакет. Если репозиторный пакет устарел, просто пометьте
его, как устаревший. Исключение из этого правила составляют пакеты из системы
контрля версий (VCS), о них чуть ниже.
Проверьте AUR. Если такой пакет уже существует и у него есть мейнтейнер, вы
не сможете залить свой пакет. Если у него нет мейнтейнера, то вы
автоматически будете его сопровождающим после обновления. Еще может быть такой
же пакет, но с другим названием, будьте внимательны.
PKGBUILD должен следовать (более-менее) стандартам и должен быть более-менее
аккуратным. В противном случае, пакет может быть удален без предупреждения.
Пакет должен быть полезен еще кому-либо кроме Вас =)
Рекомендуется проверить собранный пакет и PKGBUILD с помощью
namcap. Это не даст
100% гарантии, но на основные ошибки укажет.

AUR

Итак, Arch User Repository (AUR или АУР) — это
репозиторий, поддерживаемый и развиваемый практически исключительно сообществом
Archlinux. Есть еще отдельные люди, называемые доверенными
пользователями
(TU), на плечах которых лежит своеобразная “модерация” этого репозитория. На мой
скромный взгляд, едва ли не единственное отличие Archlinux от других
дистрибутивов — это наличие AUR’а. Отличие этого репозитория от обычных прежде
всего в том, что он не содержит архивов с исходниками или собранных пакетов

только скрипт сборки (PKGBUILD) и, возможно, дополнительные текстовые файлы.

Конечно, вручную скачивать архив с сайта AUR’а, а также проверять обновления, не
совсем удобно, поэтому существует набор
хелперов. Большинство
хелперов представляет собой обертку над pacman. Я выделю только два —
packer — минималистичный, удобный,
быстрый — и yaourt — на шелле, но
зато более функциональный. По не особо понятным мне причинам, в русскоязычном
сегменте большее распространение получил yaourt, зарубежом — packer.

Помимо хелперов, существуют также консольные клиенты для работы с AUR. Я выделю,
пожалуй, только один — python-aur. Иногда удобная альтернатива веб-интерфейсу.

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

У пакетов в AUR есть несколько характеристик, которых нет у пакетов в
официальных репозиториях:

группа — скорее для удобства поиска, сортировки. Немного помогает доверенным
пользователям.
автор, мейнтейнер, последний приславший — люди, кто, соответственно, первый
раз прислал данный пакет, сопровождает его в настоящий момент, и последний
прислал.
голоса — когда кому-либо понравился этот пакет или он находит его полезным, он
голосует. Теоретически, пакеты, имеющие больше 10 голосов могут попасть в
официальные репозитории (если найдется желающий среди доверенных пользователей).
Другой путь в официальные репозитории — попасть в список часто
используемых, но вы же
не пользуетесь pkgstats.

Usage

Before continuing, install the group. Packages belonging to this group are not required to be listed as build-time dependencies (makedepends) in PKGBUILD files.

Note:

Make sure sudo is configured properly for commands passed to pacman.

To build a package, one must first create a PKGBUILD, or build script, as described in Creating packages. Existing scripts are available from the Arch Build System (ABS) tree or the AUR. Once in possession of a , change to the directory where it is saved and run the following command to build the package:

$ makepkg

If required dependencies are missing, makepkg will issue a warning before failing. To build the package and install needed dependencies, add the flag /:

$ makepkg --syncdeps

Adding the / flag causes makepkg to remove the make dependencies later, which are no longer needed. If constantly building packages, consider using once in a while instead.

Note:

These dependencies must be available in the configured repositories; see for details. Alternatively, one can manually install dependencies prior to building ().
Only global values are used when installing dependencies, i.e any override done in a split package’s packaging function will not be used.

Once all dependencies are satisfied and the package builds successfully, a package file () will be created in the working directory. To install, use / (same as ):

$ makepkg --install

To clean up leftover files and folders, such as files extracted to the , add the option /. This is useful for multiple builds of the same package or updating the package version, while using the same build folder. It prevents obsolete and remnant files from carrying over to the new builds:

$ makepkg --clean

For more, see .

Package Details: dropbox 136.4.4345-1

Package Actions

View PKGBUILD /
View Changes
Download snapshot
Search wiki
Flag package out-of-date
Vote for this package
Enable notifications
Submit Request

Git Clone URL:	https://aur.archlinux.org/dropbox.git (read-only, click to copy)
Package Base:	dropbox
Description:	A free service that lets you bring your photos, docs, and videos anywhere and share them easily.
Upstream URL:	https://www.dropbox.com
Licenses:
Submitter:	mtorromeo
Maintainer:	mtorromeo
Last Packager:	mtorromeo
Votes:	2355
Popularity:	5.00
First Submitted:	2009-01-22 14:21
Last Updated:	2021-12-09 11:04

Dependencies (14)

dbus (dbus-elogind, dbus-git, dbus-x11, dbus-nosystemd-minimal-git, dbus-nosystemd, dbus-selinux, dbus-xdg-docs)
fontconfig (fontconfig-srb, fontconfig-infinality-ultimate, fontconfig-infinality, fontconfig-infinality-remix, fontconfig-git, fontconfig-minimal-git, fontconfig-ubuntu)
libsm
libxcomposite
libxdamage
libxmu
libxrender
libxslt (libxslt-git)
libxxf86vm
gendesk (make)
libappindicator-gtk3 (libappindicator-gtk3-ubuntu, libappindicator-bzr) (optional) – make tray icons themed under some desktop environments like KDE plasma
perl-file-mimeinfo (optional) – opening dropbox folder on some desktop environments
ufw-extras (optional) – ufw rules for dropbox
xdg-utils (mimi-git, sx-open, busking-git, xdg-utils-git, linopen, xdg-utils-mimeo, xdg-utils-handlr, xdg-utils-slock, mimi-bachoseven-git, mimejs-git) (optional) – for «Launch Dropbox Website» and file manager integration

Required by (18)

caja-dropbox (optional)
dropbox-cli
dropbox-fix
dropbox-fix2
dropbox-index-svn
dropbox-kde-systray-icons
dropbox-light-icons-git
dropbox-plasma-dark-icons-git
dropbox-plasma-light-icons-git
nautilus-dropbox
nemo-dropbox
nemo-dropbox-git
nitrotasks (optional)
python-git-remote-dropbox-git
python2-git-remote-dropbox-git
spacefm-dropbox-plugin
thunar-dropbox-git
ynab4 (optional)

dropbox.service
dropbox@.service
DropboxGlyph_Blue.svg
https://clientupdates.dropboxstatic.com/dbx-releng/client/dropbox-lnx.x86-136.4.4345.tar.gz (i686)
https://clientupdates.dropboxstatic.com/dbx-releng/client/dropbox-lnx.x86-136.4.4345.tar.gz.asc (i686)
https://clientupdates.dropboxstatic.com/dbx-releng/client/dropbox-lnx.x86_64-136.4.4345.tar.gz (x86_64)
https://clientupdates.dropboxstatic.com/dbx-releng/client/dropbox-lnx.x86_64-136.4.4345.tar.gz.asc (x86_64)
terms.txt

Overview

Packages in Arch Linux are built using the makepkg utility and the information stored in a PKGBUILD file. When runs, it searches for a in the current directory and follows the instructions in it to acquire the required files and/or compile them to be packed within a package file (). The resulting package contains binary files and installation instructions ready to be installed by pacman.

An Arch package is no more than a tar archive, or ‘tarball’, compressed using , which contains the following files generated by makepkg:

The binary files to install.
: contains all the metadata needed by pacman to deal with packages, dependencies, etc.
: contains information needed for reproducible builds. This file is present only if a package is built with pacman 5.1 or newer. See .
: contains hashes and timestamps of the files, which are included in the local database so that pacman can verify the integrity of the package.
: an optional file used to execute commands after the install/upgrade/remove stage. (This file is present only if specified in the .)
: an optional file kept by the package maintainer documenting the changes of the package. (It is not present in all packages.)

Ubuntu

Чтобы установить Dropbox в Ubuntu, вам нужно отредактировать файл sources.list в / etc / apt /. Причина в том, что программное обеспечение Dropbox не распространяется через PPA. Вместо этого они предлагают традиционные репозитории программного обеспечения. Используя инструмент редактирования текста Nano, отредактируйте свои источники.

sudo nano /etc/apt/sources.list

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

# Репозиторий обновлений Dropbox

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

deb https://linux.dropbox.com/ubuntu версия main

Обновите Ubuntu, чтобы обеспечить актуальность sources.list.

sudo apt update

Обратите внимание, что при запуске обновления возникают проблемы. В основном ошибка ключа GPG

Это потому, что у Dropbox нет правильного подписанного ключа. Чтобы добавить ключ, используйте команду ниже:

sudo apt-key adv --keyserver pgp.mit.edu --recv-keys 1C61A2656FB57B7E4DE0F4C1FC918B335044912E

Установите Dropbox на свой компьютер с Ubuntu Linux с помощью следующей команды:

sudo apt install dropbox

Version

pkgver

The version of the package. This should be the same as the version published by the author of the upstream software. It can contain letters, numbers, periods and underscores, but not a hyphen (). If the author of the software uses one, replace it with an underscore (). If the variable is used later in the , then the underscore can easily be substituted for a hyphen, e.g. .

Note: If upstream uses a timestamp versioning such as , ensure to use the reversed date, i.e. (ISO 8601 format). Otherwise it will not appear as a newer version.

Tip:

The ordering of uncommon values can be tested with , which is provided by the pacman package.

pkgrel

The release number. This is usually a positive integer number that allows to differentiate between consecutive builds of the same version of a package. As fixes and additional features are added to the that influence the resulting package, the should be incremented by 1. When a new version of the software is released, this value must be reset to 1. In exceptional cases other formats can be found in use, such as major.minor.

epoch

Warning: should only be used when absolutely required to do so.

Used to force the package to be seen as newer than any previous version with a lower epoch. This value is required to be a non-negative integer; the default is 0. It is used when the version numbering scheme of a package changes (or is alphanumeric), breaking normal version comparison logic. For example:

pkgver=5.13
pkgrel=2
epoch=1

1:5.13-2

See for more information on version comparisons.

Sources

source

An array of files needed to build the package. It must contain the location of the software source, which in most cases is a full HTTP or FTP URL. The previously set variables and can be used effectively here; e.g. .

Files can also be supplied in the same directory where the is located, and their names added to this array. Before the actual build process starts, all the files referenced in this array will be downloaded or checked for existence, and makepkg will not proceed if any is missing.

.install files are recognized automatically by makepkg and should not be included in the source array. Files in the source array with extensions .sig, .sign, or .asc are recognized by makepkg as PGP signatures and will be automatically used to verify the integrity of the corresponding source file.

Warning: The downloaded source filename must be unique because the directory can be the same for all packages. For instance, using the version number of the project as a filename potentially conflicts with other projects with the same version number. In this case, the alternative unique filename to be used is provided with the syntax ; e.g. .

Tip:

Additional architecture-specific arrays can be added by appending an underscore and the architecture name, e.g. . There must be a corresponding integrity array with checksums, e.g. .
Some servers restrict download by filtering the User-Agent string of the client or other types of restrictions, which can be circumvented with .
You can use URL to point to a folder or a file in your computer filesystem. For example, a local Git repository can be specified as .
See and for details on VCS specific options, such as targeting a specific Git branch or commit.

noextract

An array of files listed under , which should not be extracted from their archive format by makepkg. This can be used with archives that cannot be handled by or those that need to be installed as-is. If an alternative unarchiving tool is used (e.g. ), it should be added in the array and the first line of the function should extract the source archive manually; for example:

prepare() {
  lrzip -d source.tar.lrz
}

Note that while the array accepts URLs, is just the file name portion:

source=("http://foo.org/bar/foobar.tar.xz")
noextract=('foobar.tar.xz')

To extract nothing, you can do something like this:

If source contains only plain URLs without custom file names, strip the source array before the last slash:

noextract=("${source##*/}")

If source contains only entries with custom file names, strip the source array after the :: separator (taken from firefox-i18n’s PKGBUILD):

noextract=("${source%%::*}")

validpgpkeys

An array of PGP fingerprints. If used, makepkg will only accept signatures from the keys listed here and will ignore the trust values from the keyring. If the source file was signed with a subkey, makepkg will still use the primary key for comparison.

Only full fingerprints are accepted. They must be uppercase and must not contain whitespace characters.

Note: You can use to find out the fingerprint of the appropriate key.

Please read for more information.

Сборка программ из архива

Распаковывать архив можно из терминала, а можно при помощи графического интерфейса, например программой Ark или Менеджер архивов. Тут все зависит от того, как вам удобней. Для того что бы распаковать архив в терминале, нужно выполнить определенную команду. На примере с GParted такой командой будет:

Примечание, tar является утилитой командной строки для распаковки архивов. И так, затем переходим в папку с распакованной программой и смотрим какие там имеются файлы. Тут как раз имеются README:

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

Для того что бы собрать данную программу, достаточно выполнить команды, которые прописаны в инструкции. Так как мы уже распаковали данный архив, пропускаем это шаг. Если вы не знаете как перейти в терминале в директорию программы, поясню. А если знаете, то пропустите данный шаг. Для того что бы перейти в терминале в нужную директорию, используется команда “cd“. Например, у вас папка с программой находится по адресу “Загрузки – папка с программой”, выполняем команду:

После чего можно посмотреть что у нас имеется в данной директории введя команду “ls“, после чего снова вводим команду “cd” и переходим в нужную нам директорию. Например:

Теперь приступаем к сборке программы GParted. Для этого вводим команды которые написаны в файле README.

На этом этапе установки могут возникнуть проблемы с зависимостями. По этому их необходимо установить:

После того как все необходимые зависимости были установлены, снова запускаем “./configure” и продолжаем компиляцию программы как описано выше. А именно, после запуска “./configure” запускаем “make”, а затем “sudo make install”.

Установка и обновление пакетов

Установка пакетов из AUR относительно проста:

Скачайте файлы сборки, включая PKGBUILD и, возможно, другие необходимые файлы вроде юнитов systemd и патчей (но, чаще всего, не сам исходный код).
Убедитесь, что и прочие файлы не являются вредоносными или ненадёжными.
Выполните в каталоге с сохранёнными файлами. Эта команда загрузит исходный код, скомпилирует его и создаст пакет.
Выполните , чтобы установить пакет в систему.

Примечание: AUR не имеет официальной поддержки, поэтому pacman не обновляет AUR-пакеты — это ваша задача. При обновлении пакетов из официальных репозиториев все пакеты из AUR, которые от них зависят, необходимо пересобрать.

Подготовка

Прежде всего убедитесь, что в системе установлены необходимые инструменты: установите группу пакетов . В неё входят и некоторые другие инструменты, необходимые для компиляции из исходников.

Совет: Флаг при установке группы позволит не переустанавливать те пакеты, которые уже имеются в системе.

Примечание: Пакеты из AUR предполагают, что группа уже установлена. Поэтому члены этой группы никогда не указываются в списке зависимостей, необходимых для сборки.

Выберите подходящий каталог сборки. Каталог сборки — это просто место, в котором пакет будет «собран». Им может быть любой каталог в системе. В примерах ниже в качестве каталога сборки выбран .

Получение файлов

Существует несколько способов получить необходимые файлы пакета:

Клонируйте git-репозиторий, указанный в графе «URL для git clone» в разделе «Информация о пакете». Это предпочтительный метод, поскольку он позволяет получать обновления файлов пакета с помощью git pull:

$ git clone https://aur.archlinux.org/имя_пакета.git

Загрузите снимок (snapshot) либо нажав на ссылку «Загрузить снимок» под заголовком «Действия над пакетом» справа, либо командой:

$ curl -L -O https://aur.archlinux.org/cgit/aur.git/snapshot/''имя_пакета''.tar.gz

Примечание: Снимок пакета представляет собой сжатый архив, который необходимо распаковать (лучше всего — в каталог, отдельный от каталога для сборки пакетов из AUR):

Получение открытого ключа PGP (при необходимости)

Проверьте массив source в файле PKGBUILD на предмет наличия в нём файла подписи (суффикс .sig или .asc), и, если таковой присутствует, получите любой открытый ключ из массива . Подробнее см. .

Сборка пакета

Перейдите в каталог, содержащий PKGBUILD пакета:

$ cd имя_пакета

Просмотрите содержимое всех предоставленных файлов. Например, для просмотра с помощью less выполните:

$ less PKGBUILD

Совет: При обновлении пакета имеет смысл просмотреть изменения с момента последнего коммита.

Для просмотра изменений с момента последнего коммита выполните .
Для просмотра изменений с момента последнего коммита с помощью vimdiff выполните . Преимущество vimdiff в том, что можно увидеть полное содержимое каждого файла с отметками в местах изменений.

Соберите пакет. После ручной проверки целостности файлов запустите makepkg от имени обычного пользователя. Некоторые полезные флаги:

/ — при помощи pacman перед сборкой проверить зависимости и установить недостающие. Если пакет завит от пакетов из AUR, их необходимо установить вручную до сборки.
/ — установить пакет после успешной сборки. Позволяет пропустить шаг по ручной установке.
/ — удалить зависимости, необходимые только для сборки, так как они больше не требуются. Учтите, что они могут потребоваться при переустановке или обновлении пакета.
/ — удалить временные файлы после сборки, так как они больше не требуются. Эти файлы обычно необходимы только для отладки процесса сборки.

Установка пакета

После сборки можно установить пакет с помощью pacman:

# pacman -U имя_пакета-версия-архитектура.pkg.tar.zst

Примечание: Если вы изменяли PKGEXT в makepkg.conf, то имя пакета может отличаться.

Примечание: Пример выше даёт лишь краткое описание процесса сборки пакета. Настоятельно рекомендуется прочесть статьи makepkg и ABS, в которых представлена более подробная информация.

Обновление пакета

В каталоге с PKGBUILD пакета сначала обновите файлы командой

$ git pull

после чего повторите процесс сборки и установки, описанный выше.