Arch linux сборка пакетов

SYNOPSIS

makepkg [options] [ENVVAR=value] [ENVVAR+=value] .

DESCRIPTION

makepkg is a script to automate the building of packages. The requirements for using the script are a build-capable *nix platform and a custom build script for each package you wish to build (known as a PKGBUILD). See PKGBUILD(5) for details on creating your own build scripts.

The advantage to a script-based build is that the work is only done once. Once you have the build script for a package, makepkg will do the rest: download and validate source files, check dependencies, configure the build-time settings, build the package, install the package into a temporary root, make customizations, generate meta-info, and package the whole thing up for pacman to use.

makepkg uses your current locale by default and does not unset it when building packages. If you wish to share your build output with others when seeking help or for other purposes, you may wish to run «LC_ALL=C makepkg» so your logs and output are not localized.

OPTIONS

Ignore a missing or incomplete arch field in the build script. This is for rebuilding packages from source when the PKGBUILD may be slightly outdated and not updated with an arch=(‘yourarch’) field.

Do not perform any dependency checks. This will let you override and ignore any dependencies required. There is a good chance this option will break the build process if all of the dependencies are not installed.

Do not extract source files or run the prepare() function (if present); use whatever source already exists in the $srcdir/ directory. This is handy if you want to go into $srcdir/ and manually patch or tweak code, then make a package out of the result. Keep in mind that creating a patch may be a better solution to allow others to use your PKGBUILD.

For each source file in the source array of PKGBUILD, download the file if required and perform the integrity checks. No extraction or build is performed. Dependencies specified in the PKGBUILD will not be handled unless —syncdeps is used. Useful for performing subsequent offline builds.

makepkg will not build a package if a built package already exists in the PKGDEST (set in makepkg.conf(5)) directory, which may default to the current directory. This allows the built package to be overwritten.

For each source file in the source array of PKGBUILD, download the file if required and generate integrity checks. The integrity checks generated are determined by the checks present in the PKGBUILD, falling back to the value of the INTEGRITY_CHECK array in makepkg.conf(5) if these are absent This output can be redirected into your PKGBUILD for source validation using «makepkg -g >> PKGBUILD».

Источник

Arch package guidelines (Русский)

При создании пакетов для Arch Linux, придерживайтесь рекомендаций по созданию пакетов, приведенных ниже, особенно если вы собираетесь внести вклад в создание нового пакета для Arch Linux. Вам также следует ознакомиться с руководствами PKGBUILD(5) и makepkg(8) .

Прототип PKGBUILD

# Maintainer: Your Name pkgname=NAME pkgver=VERSION pkgrel=1 pkgdesc="" arch=() url="" license=('GPL') groups=() depends=() makedepends=() optdepends=() provides=() conflicts=() replaces=() backup=() options=() install= changelog= source=($pkgname-$pkgver.tar.gz) noextract=() md5sums=() #autofill using updpkgsums build() < cd "$pkgname-$pkgver" ./configure --prefix=/usr make >package() < cd "$pkgname-$pkgver" make DESTDIR="$pkgdir/" install >

Другие прототипы можно найти в /usr/share/pacman/ из пакета pacman .

Этикет упаковки

• Пакеты никогда не должны устанавливаться в /usr/local/ .
• Не вводите новые переменные или функции в сценарии сборки PKGBUILD , если пакет не может быть собран без этого, так как они могут конфликтовать с переменными и функциями, используемыми в самом makepkg.
• Если абсолютно необходима новая переменная или новая функция, снабдите ее имя подчеркиванием ( _ ), например,

optdepends=('cups: printing support' 'sane: scanners support' 'libgphoto2: digital cameras support' 'alsa-lib: sound support' 'giflib: GIF images support' 'libjpeg: JPEG images support' 'libpng: PNG images support')

• При создании описания пакета для пакета, не включайте имя пакета в виде самоссылки. Например, «Nedit — текстовый редактор для X11» может быть упрощен до «Текстовый редактор для X11». Также старайтесь, чтобы описания не превышали ~80 символов.
• Старайтесь, чтобы длина строки в PKGBUILD не превышала ~100 символов.
• По возможности удаляйте пустые строки из PKGBUILD . ( provides , replaces и т.д.)
• Общепринятой практикой является сохранение порядка полей PKGBUILD , как показано выше. Однако это не является обязательным, поскольку единственным требованием в данном контексте является правильный синтаксис bash.
• Кавычки переменных, которые могут содержать пробелы, такие как «$pkgdir» и «$srcdir» .
• Для обеспечения целостности пакетов убедитесь, что переменные целостности содержат правильные значения. Их можно обновить с помощью инструмента updpkgsums(8) .

Именование пакета

• Имена пакетов могут содержать только буквенно-цифровые символы и любые из @ , . , _ , + , — . Имена не должны начинаться с дефисов или точек. Все буквы должны быть строчными.
• Имена пакетов не должны иметь суффикс с номером версии основного релиза upstream (например, нам не нужен libfoo2, если upstream называет его libfoo v2.3.4) в случае, если ожидается, что библиотека и ее зависимости будут использовать последнюю версию библиотеки с каждым соответствующим релизом upstream. Однако для некоторых программ или зависимостей этого ожидать нельзя. В прошлом это было особенно верно для наборов инструментов виджетов, таких как GTK и Qt. Программное обеспечение, зависящее от таких наборов инструментов, обычно не может быть тривиально перенесено на новую основную версию. Поэтому в случаях, когда программы не могут тривиально продолжать развиваться вместе со своими зависимостями, имена пакетов должны содержать суффикс основной версии (например, gtk2, gtk3, qt4, qt5). Для случаев, когда большинство зависимостей могут продолжать распространяться вместе с новейшим релизом, но некоторые не могут (например, закрытый исходный код, требующий libpng12 или аналогичный), устаревшая версия пакета может называться libfoo1, в то время как текущая версия — просто libfoo.

Версионирование пакетов

• Версии пакетов (например, PKGBUILD#pkgver) должны совпадать с версией, выпущенной автором. Версии могут включать буквы, если это необходимо (например, версия nmap — 2.54BETA32 ). Теги версий не должны включать дефисы!. Только буквы, цифры и точки.
• Выпуски пакетов (т.е. PKGBUILD#pkgrel) являются специфическими для пакетов Arch Linux. Они позволяют пользователям различать более новые и более старые сборки пакетов. Когда новая версия пакета выпускается впервые, счетчик релизов начинается с 1. Затем, по мере внесения исправлений и оптимизаций, пакет будет перевыпущен для публики Arch Linux, и номер релиза будет увеличиваться. Когда выходит новая версия — счетчик релизов обнуляется до 1. Теги релизов пакетов следуют тем же ограничениям именования, что и теги версий.

Зависимости пакетов

• Не полагайтесь на переходные зависимости в любой из PKGBUILD#Dependencies, так как они могут сломаться, если одна из зависимостей будет обновлена.
• Список всех прямых библиотечных зависимостей. Чтобы определить их можно использовать find-libdeps(1) (часть devtools ).

Взаимоотношения пакетов

• Не добавляйте $pkgname в PKGBUILD#provides, так как он всегда неявно предоставляется пакетом.
• Перечислите все внешние разделяемые библиотеки пакета в PKGBUILD#provides (например, ‘libsomething.so’ ). Для их идентификации можно использовать find-libprovides(1) (часть devtools ).

Исходники пакетов

• По возможности следует использовать HTTPS источники ( https:// для tar-болов, git+https:// для git-источников).
• Исходники должны быть проверены с помощью PGP-подписей везде, где это возможно (это может повлечь за собой сборку из git-тегов вместо исходного tar-бола, если upstream подписывает коммиты и теги, но не tar-болы)
• При сборке из git-тега — вместо имени тега используйте хэш объекта, полученный из git rev-parse :

_tag=1234567890123456789012345678901234567890 # git rev-parse «v$pkgver» source=(git+https://$url.git?signed#tag=$_tag) pkgver()

• Не снижайте безопасность или валидность пакета (например, удаляя проверку контрольной суммы или проверку подписи PGP), потому что вышестоящий релиз сломан или в нем внезапно отсутствует определенная функция (например, подпись PGP отсутствует в новом релизе).
• Исходники должны быть уникальными в srcdir . (это может потребовать переименования их при загрузке, например, «$.tar.gz::https://$.tld/download/$.tar.gz» )
• Избегайте использования определенных зеркал (например, на sourceforge) для загрузки, так как они могут стать недоступными.

Работа с upstream

Считается лучшей практикой тесно сотрудничать с upstream, когда это возможно. Это подразумевает сообщение о проблемах, связанных со сборкой и тестированием пакета.

• Сразу же сообщайте о проблемах в upstream.
• По возможности добавляйте исправления.
• Добавляйте комментарии со ссылками на соответствующие (upstream) баг-трекеры в PKGBUILD (это особенно важно, так как гарантирует, что другие упаковщики смогут понять изменения и также работать с пакетом).

Рекомендуется отслеживать upstream с помощью таких инструментов, как nvchecker или urlwatch , чтобы быть в курсе новых стабильных релизов.

Каталоги

• Файлы конфигурации должны быть размещены в каталоге /etc . Если существует более одного файла конфигурации, обычно принято использовать подкаталог, чтобы сохранить область /etc как можно более чистой. Используйте /etc/pkg , где pkg — имя пакета (или подходящая альтернатива, например, apache использует /etc/httpd/ ).
• Файлы пакетов должны следовать этим общим рекомендациям по каталогам:

• Пакеты не должны содержать ни одного из следующих каталогов:
  • /bin
  • /sbin
  • /dev
  • /home
  • /srv
  • /media
  • /mnt
  • /proc
  • /root
  • /selinux
  • /sys
  • /tmp
  • /var/tmp
  • /run

  Функции makepkg

  При использовании makepkg для сборки пакета, он автоматически делает следующее:

  1. Проверяет, установлены ли пакеты из dependencies и makedepends.
  2. Загружает исходные файлы с серверов
  3. Проверяет целостность исходных файлов
  4. Распаковывает исходные файлы
  5. Применяет все необходимые патчи
  6. Собирает программное обеспечение и устанавливает его в поддельный корень
  7. Удаляет символы из двоичных файлов
  8. Удаляет отладочные символы из библиотек
  9. Сжимает руководства и/или страницы info.
  10. Генерирует мета-файл пакета, включаемый в каждый пакет.
  11. Сжимает фальшивый корень в файл пакета
  12. Сохраняет файл пакета в настроенном каталоге назначения (т.е. в текущем рабочем каталоге по умолчанию)

  Архитектуры

  Массив arch должен содержать ‘x86_64’ , если скомпилированный пакет зависит от архитектуры. В противном случае используйте ‘any’ для независимых от архитектуры пакетов.

  Лицензии

  Воспроизводимые сборки

  Arch работает над тем, чтобы сделать все пакеты воспроизводимыми. Упаковщик может проверить, является ли пакет воспроизводимым с помощью makerepropkg из devtools или repro из archlinux-repro .

  $ makerepropkg $pkgname-1-1-any.pkg.tar.zst

  $ repro -f $pkgname-1-1-any.pkg.tar.zst

  Если временная метка требуется во время сборки, используйте переменную окружения SOURCE_DATE_EPOCH . Формат — документированный восходящим потоком [устаревшая ссылка 2023-06-17 ⓘ] .

  Дополнительные рекомендации

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

  Пакеты, представленные в AUR, должны дополнительно соответствовать правилам публикации пакетов в AUR.

  Источник