Руководство PKGBUILD VCS
Views
Actions
Namespaces
Variants
Tools
Version control systems может использоваться для поиска исходного кода как обычных статически версионированных пакетов, так и последней (trunk) версии ветки разработки. В этой статье рассматриваются оба случая.
Руководство
- Суффиксы
pkgname
with-cvs
,-svn
,-hg
,-darcs
,-bzr
,-git
и тд, если только пакет не относится к определенному выпуску.
- Если результирующий пакет отличается после изменения зависимостей, URL, источников и т.д., увеличение
pkgrel
является обязательным. Менятьpkgver
необязательно.
--holdver
можно использовать для предотвращения обновления makepkg вpkgver
. (см.: makepkg(8))
- Укажите, с чем пакет конфликтует и что предоставляет (например, для fluxbox-git:
conflicts=('fluxbox')
иprovides=('fluxbox')
).
replaces=()
обычно вызывает ненужные проблемы и его следует избегать.
- При использовании cvsroot используйте
anonymous:@
, а неanonymous@
, чтобы избежать необходимости вводить пустой пароль илиanonymous:password@
, если он требуется.
- Включите соответствующий инструмент VCS в
makedepends=()
(cvs
,subversion
,git
, ...).
Источники VCS
Начиная с pacman
4.1, источники VCS должны быть указаны в массиве source=()
и будут рассматриваться как любой другой источник. <codemakepkg> будет клонировать/выверять/разветвлять репозиторий в $SRCDEST
(то же, что и $startdir
, если не задано в makepkg.conf(5)) и скопирует его в $srcdir
(специфическим для каждой VCS способом). Локальный репозиторий остается нетронутым, таким образом отпадает необходимость в каталоге -build
.
Общий формат массива VCS source=()
следующий:
source=('[folder::][vcs+]url[#fragment]')
folder
(необязательно) используется для изменения имени репо по умолчанию на что-то более подходящее (например, чемtrunk
) или для сохранения предыдущих источниковvcs+
необходим для URL, которые не отражают тип VCS, например,git+http://some_repo
.url
- это URL удаленного или локального репозитория.#fragment
(необязательно) необходим для извлечения конкретной ветки или коммита. Смотритеman PKGBUILD
для получения дополнительной информации о фрагментах, доступных для каждого VCS.
Пример массива источника Git:
source=('project_name::git+http://project_url#branch=project_branch')
Функция pkgver()
Автопереход pkgver
теперь осуществляется с помощью специальной функции pkgver()
. Это позволяет лучше контролировать pkgver
, и сопровождающие должны отдавать предпочтение pkgver
, которая имеет значение.
Рекомендуется иметь следующий формат версии: RELEASE.rREVISION, где REVISION - монотонно возрастающее число, уникально идентифицирующее дерево источника (это делают ревизии VCS). Последний тег VCS может быть использован для RELEASE. Если нет публичных релизов и тегов репозиториев, то в качестве номера релиза можно использовать ноль или полностью отказаться от RELEASE и использовать номер версии, который выглядит как rREVISION. Если есть публичные релизы, но репозиторий не имеет тегов, то разработчик должен получить версию релиза каким-то иным образом, например, путем разбора файлов проекта.
Ниже приведены примеры, показывающие "предполагаемый" вывод:
Git
Используя аннотированный тег последнего коммита:
pkgver() { cd "$srcdir/repo" git describe --long | sed -E 's/([^-]*-g)/r\1/;s/-/./g' }
2.0.r6.ga17a017
Использование неаннотированного тега последнего коммита:
pkgver() { cd "$srcdir/repo" git describe --long --tags | sed -E 's/([^-]*-g)/r\1/;s/-/./g' }
0.71.r115.gd95ee07
Если тегов нет, то используйте количество ревизий с начала истории:
pkgver() { cd "$srcdir/repo" printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)" }
r1142.a17a017
Подверсия
pkgver() { cd "$srcdir/repo" local ver="$(svnversion)" printf "r%s" "${ver//[[:alpha:]]}" }
r8546
Непостоянная
pkgver() { cd "$srcdir/repo" printf "r%s.%s" "$(hg identify -n)" "$(hg identify -i)" }
r2813.75881cc5391e
Базис
pkgver() { cd "$srcdir/repo" printf "r%s" "$(bzr revno)" }
r830
Запасной вариант
Текущая дата может быть использована в случае, если из репозитория не удалось извлечь удовлетворительный pkgver
:
pkgver() { date +%Y%m%d }
20130408
Хотя он не позволяет однозначно определить состояние исходного дерева, поэтому по возможности избегайте его.
Советы
A sample Git PKGBUILD
# Maintainer: Dave Reisner <d@falconindy.com> # Contributor: William Giokas (KaiSforza) <1007380@gmail.com> pkgname=expac-git pkgver=0.0.0 pkgrel=1 pkgdesc="Pacman database extraction utility" arch=('i686' 'x86_64') url="https://github.com/falconindy/expac" license=('MIT') depends=('pacman') makedepends=('git') conflicts=('expac') provides=('expac') # The git repo is detected by the 'git:' or 'git+' beginning. The branch # '$pkgname' is then checked out upon cloning, expediating versioning: #source=('git+https://github.com/falconindy/expac.git' source=("$pkgname"::'git://github.com/falconindy/expac.git' 'expac_icon.png') # Because the sources are not static, skip Git checksum: md5sums=('SKIP' '020c36e38466b68cbc7b3f93e2044b49') pkgver() { cd "$srcdir/$pkgname" # Use the tag of the last commit git describe --long | sed -E 's/([^-]*-g)/r\1/;s/-/./g' } build() { cd "$srcdir/$pkgname" make } package() { cd "$srcdir/$pkgname" make PREFIX=/usr DESTDIR="$pkgdir" install install -Dm644 "$srcdir/expac_icon.png" "$pkgdir/usr/share/pixmaps/expac.png" }
Подмодули Git
Подмодули Git немного сложнее. Идея заключается в том, чтобы добавить URL-адреса самих подмодулей непосредственно в массив sources, а затем ссылаться на них во время prepare(). Это может выглядеть следующим образом:
source=("git://somewhere.org/something/something.git" "git://somewhere.org/mysubmodule/mysubmodule.git") prepare() { cd something git submodule init git config submodule.mysubmodule.url $srcdir/mysubmodule git submodule update }