Difference between revisions of "VCS PKGBUILD Guidelines/ru"
Views
Actions
Namespaces
Variants
Tools
(Created page with "=== Функция pkgver() === Автопереход {{ic|pkgver}} теперь осуществляется с помощью специальной функции {{ic|pk...") |
|||
Line 36: | Line 36: | ||
=== Функция pkgver() === | === Функция pkgver() === | ||
Автопереход {{ic|pkgver}} теперь осуществляется с помощью специальной функции {{ic|pkgver()}}. Это позволяет лучше контролировать {{ic|pkgver}}, и сопровождающие должны отдавать предпочтение {{ic|pkgver}}, которая имеет | Автопереход {{ic|pkgver}} теперь осуществляется с помощью специальной функции {{ic|pkgver()}}. Это позволяет лучше контролировать {{ic|pkgver}}, и сопровождающие должны отдавать предпочтение {{ic|pkgver}}, которая имеет значение. | ||
It is recommended to have following version format: ''RELEASE.rREVISION'' where ''REVISION'' is a monotonically increasing number that uniquely identifies the source tree (VCS revisions do this). The last VCS tag can be used for ''RELEASE''. If there are no public releases and no repository tags then zero could be used as a release number or you can drop ''RELEASE'' completely and use version number that looks like ''rREVISION''. If there are public releases but repo has no tags then developer should get the release version somehow e.g. by parsing the project files. | It is recommended to have following version format: ''RELEASE.rREVISION'' where ''REVISION'' is a monotonically increasing number that uniquely identifies the source tree (VCS revisions do this). The last VCS tag can be used for ''RELEASE''. If there are no public releases and no repository tags then zero could be used as a release number or you can drop ''RELEASE'' completely and use version number that looks like ''rREVISION''. If there are public releases but repo has no tags then developer should get the release version somehow e.g. by parsing the project files. |
Revision as of 04:39, 1 March 2023
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
, которая имеет значение.
It is recommended to have following version format: RELEASE.rREVISION where REVISION is a monotonically increasing number that uniquely identifies the source tree (VCS revisions do this). The last VCS tag can be used for RELEASE. If there are no public releases and no repository tags then zero could be used as a release number or you can drop RELEASE completely and use version number that looks like rREVISION. If there are public releases but repo has no tags then developer should get the release version somehow e.g. by parsing the project files.
Following are some examples showing the intended output:
Git
Using the annotated tag of the last commit:
pkgver() { cd "$srcdir/repo" git describe --long | sed -E 's/([^-]*-g)/r\1/;s/-/./g' }
2.0.r6.ga17a017
Using the unannotated tag of the last commit:
pkgver() { cd "$srcdir/repo" git describe --long --tags | sed -E 's/([^-]*-g)/r\1/;s/-/./g' }
0.71.r115.gd95ee07
If there are no tags then use number of revisions since beginning of the history:
pkgver() { cd "$srcdir/repo" printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)" }
r1142.a17a017
Subversion
pkgver() { cd "$srcdir/repo" local ver="$(svnversion)" printf "r%s" "${ver//[[:alpha:]]}" }
r8546
Mercurial
pkgver() { cd "$srcdir/repo" printf "r%s.%s" "$(hg identify -n)" "$(hg identify -i)" }
r2813.75881cc5391e
Bazaar
pkgver() { cd "$srcdir/repo" printf "r%s" "$(bzr revno)" }
r830
Fallback
The current date can be used, in case no satisfactory pkgver
can be extracted from the repository:
pkgver() { date +%Y%m%d }
20130408
Although it does not identify source tree state uniquely, so avoid it if possible.
Советы
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 Submodules
Git submodules are a little tricky to do. The idea is to add the URLs of the submodules themselves directly to the sources array and then reference them during prepare(). This could look like this:
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 }