Manjaro Difference between revisions of "VCS PKGBUILD Guidelines/ru"

Difference between revisions of "VCS PKGBUILD Guidelines/ru"

From Manjaro
(Created page with "=== Функция pkgver() === Автопереход {{ic|pkgver}} теперь осуществляется с помощью специальной функции {{ic|pk...")
 
(15 intermediate revisions by the same user not shown)
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.
Рекомендуется иметь следующий формат версии: ''RELEASE.rREVISION'', где ''REVISION'' - монотонно возрастающее число, уникально идентифицирующее дерево источника (это делают ревизии VCS). Последний тег VCS может быть использован для ''RELEASE''. Если нет публичных релизов и тегов репозиториев, то в качестве номера релиза можно использовать ноль или полностью отказаться от ''RELEASE'' и использовать номер версии, который выглядит как ''rREVISION''. Если есть публичные релизы, но репозиторий не имеет тегов, то разработчик должен получить версию релиза каким-то иным образом, например, путем разбора файлов проекта.


Following are some examples showing the ''intended'' output:
Ниже приведены примеры, показывающие "предполагаемый" вывод:


==== Git ====
==== Git ====


Using the annotated tag of the last commit:
Используя аннотированный тег последнего коммита:


{{hc|<nowiki>pkgver() {
{{hc|<nowiki>pkgver() {
Line 53: Line 53:
}}
}}


Using the unannotated tag of the last commit:
Использование неаннотированного тега последнего коммита:


{{hc|<nowiki>pkgver() {
{{hc|<nowiki>pkgver() {
Line 62: Line 62:
}}
}}


If there are no tags then use number of revisions since beginning of the history:
Если тегов нет, то используйте количество ревизий с начала истории:


{{hc|<nowiki>pkgver() {
{{hc|<nowiki>pkgver() {
Line 71: Line 71:
}}
}}


{{Note|SHA1 (in this case {{ic|a17a017}}) is not used in the version comparison and can be omitted, although it allows quick identification of the exact revision used and might be useful during debugging.}}
{{BoxInfo|Примечание|SHA1 (в данном случае {{ic|a17a017}}) не используется при сравнении версий и может быть опущен, хотя он позволяет быстро определить точную используемую ревизию и может быть полезен при отладке.}}


==== Subversion ====
==== Подверсия ====
{{hc|<nowiki>pkgver() {
{{hc|<nowiki>pkgver() {
   cd "$srcdir/repo"
   cd "$srcdir/repo"
Line 82: Line 82:
}}
}}


{{Note|If the project has releases you should use them instead of the {{ic|0.}}.}}
{{BoxInfo|Примечание|Если у проекта есть релизы, вы должны использовать их вместо {{ic|0.}}.}}


==== Mercurial ====
==== Непостоянная ====
{{hc|<nowiki>pkgver() {
{{hc|<nowiki>pkgver() {
   cd "$srcdir/repo"
   cd "$srcdir/repo"
Line 92: Line 92:
}}
}}


==== Bazaar ====
==== Базис ====
{{hc|<nowiki>pkgver() {
{{hc|<nowiki>pkgver() {
   cd "$srcdir/repo"
   cd "$srcdir/repo"
Line 100: Line 100:
}}
}}


==== Fallback ====
==== Запасной вариант ====
The current date can be used, in case no satisfactory {{ic|pkgver}} can be extracted from the repository:
Текущая дата может быть использована в случае, если из репозитория не удалось извлечь удовлетворительный {{ic|pkgver}}:


{{hc|<nowiki>pkgver() {
{{hc|<nowiki>pkgver() {
Line 109: Line 109:
}}
}}


Although it does not identify source tree state uniquely, so avoid it if possible.
Хотя он не позволяет однозначно определить состояние исходного дерева, поэтому по возможности избегайте его.


== Советы ==
== Советы ==
Line 154: Line 154:
  }
  }


=== Git Submodules ===
=== Подмодули Git ===
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:
Подмодули Git немного сложнее. Идея заключается в том, чтобы добавить URL-адреса самих подмодулей непосредственно в массив sources, а затем ссылаться на них во время prepare(). Это может выглядеть следующим образом:


  source=("git://somewhere.org/something/something.git"
  source=("git://somewhere.org/something/something.git"

Latest revision as of 04:46, 1 March 2023

Other languages:
English • ‎Türkçe • ‎русский

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: bzr, git, hg и svn. Список поддерживаемых VCS см. в разделе fragment в man PKGBUILD или PKGBUILD(5).

Начиная с 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


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

Подверсия

pkgver() {
  cd "$srcdir/repo"
  local ver="$(svnversion)"
  printf "r%s" "${ver//[[:alpha:]]}"
}
r8546


Примечание
Если у проекта есть релизы, вы должны использовать их вместо 0..

Непостоянная

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
}
Cookies help us deliver our services. By using our services, you agree to our use of cookies.