Manjaro Difference between revisions of "VCS PKGBUILD Guidelines"

Difference between revisions of "VCS PKGBUILD Guidelines"

From Manjaro
imported>Philm
(Created page with "Version control systems can be used for retrieval of source code for both usual statically versioned packages and latest (trunk) version of a de...")
 
(Marked this version for translation)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
<languages/>
__TOC__
<translate>
<!--T:1-->
[[Wikipedia:Revision_control|Version control systems]] can be used for retrieval of source code for both usual statically versioned packages and latest (trunk) version of a development branch. This article covers both cases.
[[Wikipedia:Revision_control|Version control systems]] can be used for retrieval of source code for both usual statically versioned packages and latest (trunk) version of a development branch. This article covers both cases.


== Guidelines ==
== Guidelines == <!--T:2-->


<!--T:3-->
* Suffix {{Ic|pkgname}} with {{Ic|-cvs}}, {{Ic|-svn}}, {{Ic|-hg}}, {{Ic|-darcs}}, {{Ic|-bzr}}, {{Ic|-git}} etc. unless the package fetches a specific release.
* Suffix {{Ic|pkgname}} with {{Ic|-cvs}}, {{Ic|-svn}}, {{Ic|-hg}}, {{Ic|-darcs}}, {{Ic|-bzr}}, {{Ic|-git}} etc. unless the package fetches a specific release.


<!--T:4-->
* If the resulting package is different after changing the dependencies, URL, sources, etc. increasing the {{Ic|pkgrel}} is mandatory. Touching the {{ic|pkgver}} is not.
* If the resulting package is different after changing the dependencies, URL, sources, etc. increasing the {{Ic|pkgrel}} is mandatory. Touching the {{ic|pkgver}} is not.


<!--T:5-->
* {{Ic|--holdver}} can be used to prevent [[makepkg]] from updating the {{ic|pkgver}} (see: [https://www.archlinux.org/pacman/makepkg.8.html makepkg(8)])
* {{Ic|--holdver}} can be used to prevent [[makepkg]] from updating the {{ic|pkgver}} (see: [https://www.archlinux.org/pacman/makepkg.8.html makepkg(8)])


<!--T:6-->
* Include what the package conflicts with and provides (e.g. for {{AUR|fluxbox-git}}: {{Ic|1=conflicts=('fluxbox')}} and {{Ic|1=provides=('fluxbox')}}).
* Include what the package conflicts with and provides (e.g. for {{AUR|fluxbox-git}}: {{Ic|1=conflicts=('fluxbox')}} and {{Ic|1=provides=('fluxbox')}}).


<!--T:7-->
* {{Ic|1=replaces=()}} generally causes unnecessary problems and should be avoided.
* {{Ic|1=replaces=()}} generally causes unnecessary problems and should be avoided.


<!--T:8-->
* When using the cvsroot, use {{Ic|anonymous:@}} rather than {{Ic|anonymous@}} to avoid having to enter a blank password or {{Ic|anonymous:password@}}, if one is required.
* When using the cvsroot, use {{Ic|anonymous:@}} rather than {{Ic|anonymous@}} to avoid having to enter a blank password or {{Ic|anonymous:password@}}, if one is required.


<!--T:9-->
* Include the appropriate VCS tool in {{Ic|1=makedepends=()}} ({{ic|cvs}}, {{ic|subversion}}, {{ic|git}}, ...).
* Include the appropriate VCS tool in {{Ic|1=makedepends=()}} ({{ic|cvs}}, {{ic|subversion}}, {{ic|git}}, ...).


=== VCS sources ===
=== VCS sources === <!--T:10-->
{{Note|Pacman 4.1 supports the following VCS sources: {{ic|bzr}}, {{ic|git}}, {{ic|hg}} and {{ic|svn}}. See the {{ic|fragment}} section of {{ic|man PKGBUILD}} or [https://www.archlinux.org/pacman/PKGBUILD.5.html PKGBUILD(5)] for a list of supported VCS.}}
{{Note|Pacman 4.1 supports the following VCS sources: {{ic|bzr}}, {{ic|git}}, {{ic|hg}} and {{ic|svn}}. See the {{ic|fragment}} section of {{ic|man PKGBUILD}} or [https://www.archlinux.org/pacman/PKGBUILD.5.html PKGBUILD(5)] for a list of supported VCS.}}


<!--T:11-->
Starting with {{ic|pacman}} 4.1, the VCS sources should be specified in the {{ic|1=source=()}} array and will be treated like any other source. {{ic|makepkg}} will clone/checkout/branch the repo into {{ic|$SRCDEST}} (same as {{ic|$startdir}} if not set in [https://www.archlinux.org/pacman/makepkg.conf.5.html makepkg.conf(5)]) and copy it to {{ic|$srcdir}} (in a specific way to each VCS). The local repo is left untouched, thus invalidating the need for a {{ic|-build}} directory.
Starting with {{ic|pacman}} 4.1, the VCS sources should be specified in the {{ic|1=source=()}} array and will be treated like any other source. {{ic|makepkg}} will clone/checkout/branch the repo into {{ic|$SRCDEST}} (same as {{ic|$startdir}} if not set in [https://www.archlinux.org/pacman/makepkg.conf.5.html makepkg.conf(5)]) and copy it to {{ic|$srcdir}} (in a specific way to each VCS). The local repo is left untouched, thus invalidating the need for a {{ic|-build}} directory.


<!--T:12-->
The general format of a VCS {{ic|1=source=()}} array is:
The general format of a VCS {{ic|1=source=()}} array is:
  source=('[folder::][vcs+]url[#fragment]')
  source=('[folder::][vcs+]url[#fragment]')


<!--T:13-->
* {{ic|folder}} (optional) is used to change the default repo name to something more relevant (e.g. than {{ic|trunk}}) or to preserve the previous sources
* {{ic|folder}} (optional) is used to change the default repo name to something more relevant (e.g. than {{ic|trunk}}) or to preserve the previous sources
* {{ic|vcs+}} is needed for URLs that do not reflect the VCS type, e.g. {{ic|git+http://some_repo}}.
* {{ic|vcs+}} is needed for URLs that do not reflect the VCS type, e.g. {{ic|git+http://some_repo}}.
Line 30: Line 44:
* {{ic|#fragment}} (optional) is needed to pull a specific branch or commit. See {{ic|man PKGBUILD}} for more information on the fragments available for each VCS.
* {{ic|#fragment}} (optional) is needed to pull a specific branch or commit. See {{ic|man PKGBUILD}} for more information on the fragments available for each VCS.


<!--T:14-->
An example Git source array:
An example Git source array:
  source=('project_name::git+http://project_url#branch=project_branch')
  source=('project_name::git+http://project_url#branch=project_branch')


=== The pkgver() function ===
=== The pkgver() function === <!--T:15-->
The {{ic|pkgver}} autobump is now achieved via a dedicated {{ic|pkgver()}} function. This allows for better control over the {{ic|pkgver}}, and maintainers should favor a {{ic|pkgver}} that makes sense.
The {{ic|pkgver}} autobump is now achieved via a dedicated {{ic|pkgver()}} function. This allows for better control over the {{ic|pkgver}}, and maintainers should favor a {{ic|pkgver}} that makes sense.


<!--T:16-->
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.


<!--T:17-->
Following are some examples showing the ''intended'' output:
Following are some examples showing the ''intended'' output:


==== Git ====
==== Git ==== <!--T:18-->


<!--T:19-->
Using the annotated tag of the last commit:
Using the annotated tag of the last commit:


<!--T:20-->
{{hc|<nowiki>pkgver() {
{{hc|<nowiki>pkgver() {
   cd "$srcdir/repo"
   cd "$srcdir/repo"
Line 51: Line 70:
}}
}}


<!--T:21-->
Using the unannotated tag of the last commit:
Using the unannotated tag of the last commit:


<!--T:22-->
{{hc|<nowiki>pkgver() {
{{hc|<nowiki>pkgver() {
   cd "$srcdir/repo"
   cd "$srcdir/repo"
Line 60: Line 81:
}}
}}


<!--T:23-->
If there are no tags then use number of revisions since beginning of the history:
If there are no tags then use number of revisions since beginning of the history:


<!--T:24-->
{{hc|<nowiki>pkgver() {
{{hc|<nowiki>pkgver() {
   cd "$srcdir/repo"
   cd "$srcdir/repo"
Line 69: Line 92:
}}
}}


<!--T:25-->
{{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.}}
{{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.}}


==== Subversion ====
==== Subversion ==== <!--T:26-->
{{hc|<nowiki>pkgver() {
{{hc|<nowiki>pkgver() {
   cd "$srcdir/repo"
   cd "$srcdir/repo"
Line 80: Line 104:
}}
}}


<!--T:27-->
{{Note|If the project has releases you should use them instead of the {{ic|0.}}.}}
{{Note|If the project has releases you should use them instead of the {{ic|0.}}.}}


==== Mercurial ====
==== Mercurial ==== <!--T:28-->
{{hc|<nowiki>pkgver() {
{{hc|<nowiki>pkgver() {
   cd "$srcdir/repo"
   cd "$srcdir/repo"
Line 90: Line 115:
}}
}}


==== Bazaar ====
==== Bazaar ==== <!--T:29-->
{{hc|<nowiki>pkgver() {
{{hc|<nowiki>pkgver() {
   cd "$srcdir/repo"
   cd "$srcdir/repo"
Line 98: Line 123:
}}
}}


==== Fallback ====
==== Fallback ==== <!--T:30-->
The current date can be used, in case no satisfactory {{ic|pkgver}} can be extracted from the repository:
The current date can be used, in case no satisfactory {{ic|pkgver}} can be extracted from the repository:


<!--T:31-->
{{hc|<nowiki>pkgver() {
{{hc|<nowiki>pkgver() {
   date +%Y%m%d
   date +%Y%m%d
Line 107: Line 133:
}}
}}


<!--T:32-->
Although it does not identify source tree state uniquely, so avoid it if possible.
Although it does not identify source tree state uniquely, so avoid it if possible.


== Tips ==
== Tips == <!--T:33-->


=== A sample Git PKGBUILD ===
=== A sample Git PKGBUILD === <!--T:34-->
  # Maintainer: Dave Reisner <d@falconindy.com>  
  # Maintainer: Dave Reisner <d@falconindy.com>  
  # Contributor: William Giokas (KaiSforza) <1007380@gmail.com>
  # Contributor: William Giokas (KaiSforza) <1007380@gmail.com>
Line 152: Line 179:
  }
  }


=== Git Submodules ===
=== Git Submodules === <!--T:35-->
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 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"
  <!--T:36-->
source=("git://somewhere.org/something/something.git"
         "git://somewhere.org/mysubmodule/mysubmodule.git")
         "git://somewhere.org/mysubmodule/mysubmodule.git")
   
   
Line 164: Line 192:
     git submodule update
     git submodule update
  }
  }
</translate>
[[Category:Contents Page{{#translation:}}]]

Latest revision as of 19:01, 7 September 2021

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

Version control systems can be used for retrieval of source code for both usual statically versioned packages and latest (trunk) version of a development branch. This article covers both cases.

Guidelines

  • Suffix pkgname with -cvs, -svn, -hg, -darcs, -bzr, -git etc. unless the package fetches a specific release.
  • If the resulting package is different after changing the dependencies, URL, sources, etc. increasing the pkgrel is mandatory. Touching the pkgver is not.
  • Include what the package conflicts with and provides (e.g. for fluxbox-git: conflicts=('fluxbox') and provides=('fluxbox')).
  • replaces=() generally causes unnecessary problems and should be avoided.
  • When using the cvsroot, use anonymous:@ rather than anonymous@ to avoid having to enter a blank password or anonymous:password@, if one is required.
  • Include the appropriate VCS tool in makedepends=() (cvs, subversion, git, ...).

VCS sources

Note
Pacman 4.1 supports the following VCS sources: bzr, git, hg and svn. See the fragment section of man PKGBUILD or PKGBUILD(5) for a list of supported VCS.

Starting with pacman 4.1, the VCS sources should be specified in the source=() array and will be treated like any other source. makepkg will clone/checkout/branch the repo into $SRCDEST (same as $startdir if not set in makepkg.conf(5)) and copy it to $srcdir (in a specific way to each VCS). The local repo is left untouched, thus invalidating the need for a -build directory.

The general format of a VCS source=() array is:

source=('[folder::][vcs+]url[#fragment]')
  • folder (optional) is used to change the default repo name to something more relevant (e.g. than trunk) or to preserve the previous sources
  • vcs+ is needed for URLs that do not reflect the VCS type, e.g. git+http://some_repo.
  • url is the URL to the distant or local repo
  • #fragment (optional) is needed to pull a specific branch or commit. See man PKGBUILD for more information on the fragments available for each VCS.

An example Git source array:

source=('project_name::git+http://project_url#branch=project_branch')

The pkgver() function

The pkgver autobump is now achieved via a dedicated pkgver() function. This allows for better control over the pkgver, and maintainers should favor a pkgver that makes sense.

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


Note
SHA1 (in this case 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.

Subversion

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


Note
If the project has releases you should use them instead of the 0..

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.

Tips

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