Difference between revisions of "VCS package guidelines"

From ArchWiki
Jump to: navigation, search
(Tips: add tips)
m (Tips: - Ellipsis: A three-dot symbol used to show an incomplete statement. :))
(20 intermediate revisions by 11 users not shown)
Line 1: Line 1:
[[Category:Package development (English)]]
+
[[Category:Package development]]
{{i18n|VCS PKGBUILD Guidelines}}
+
[[it:VCS PKGBUILD Guidelines]]
{{Article summary start}}
+
[[zh-CN:VCS PKGBUILD Guidelines]]
{{Article summary text|Creating PKGBUILDs for software managed with version control systems.}}
+
[[zh-TW:VCS PKGBUILD Guidelines]]
{{Article summary heading|Related}}
+
{{Package Guidelines}}
{{Article summary wiki|Arch Build System}}
+
{{Article summary wiki|Arch User Repository}}
+
{{Article summary wiki|Creating Packages}}
+
{{Article summary wiki|makepkg}}
+
{{Article summary wiki|pacman}}
+
{{Article summary wiki|PKGBUILD}}
+
{{Article summary end}}
+
  
Guidelines for creating PKGBUILDs for software managed with version control systems.
+
[[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 packages. This article covers both cases.
  
 
== Prototypes ==
 
== Prototypes ==
 
+
The [[ABS]] package provides prototypes for [[cvs]], [[svn]], [[git]], [[mercurial]], and [[Wikipedia:darcs|darcs]] [[PKGBUILD]]s. When {{Pkg|abs}} is installed, you can find them in {{ic|/usr/share/pacman}}. Latest versions can be found in the [https://projects.archlinux.org/abs.git/tree/prototypes prototypes directory in the ABS Git repository].
The {{Package Official|abs}} package provides prototypes for cvs, svn, git, mercurial, and darcs PKGBUILDs. When abs is installed, you can find them in {{Filename|/usr/share/pacman}}.
+
  
 
== Guidelines ==
 
== Guidelines ==
 +
* Properly suffix {{Ic|pkgname}} with {{Ic|-cvs}}, {{Ic|-svn}}, {{Ic|-hg}}, {{Ic|-darcs}}, {{Ic|-bzr}}, {{Ic|-git}} etc. If the package tracks a moving development trunk it should be given a suffix. If the package fetches a release from a VCS tag then it should not be given a suffix. Use this rule of thumb: if the output of the package depends on the time at which it was compiled, append a suffix; otherwise do not.
  
* Properly suffix {{Codeline|pkgname}} with {{Codeline|-cvs}}, {{Codeline|-svn}}, {{Codeline|-hg}}, {{Codeline|-darcs}}, {{Codeline|-bzr}} or {{Codeline|-git}}. If the package tracks a moving development trunk it should be given a suffix. If the package fetches a release from a VCS tag then it should not be given a suffix. Use this rule of thumb: if the output of the package depends on the time at which it was compiled, append a suffix; otherwise do not.
+
* A VCS package may be updated as and when needed to adopt changes to the build system, including ammendments to dependencies, URL, sources, etc. If the revision number remains the same after such an update, but produces a resulting binary which is different, increasing the {{Ic|pkgrel}} is mandatory. If both the revision number and the resulting binary remain the same, {{Ic|pkgrel}} should be kept intact. There is no need to update the VCS package just to accommodate a revision bump, but one may choose to do so.
  
* A VCS package may be updated as and when needed to adopt changes to the build system, including ammendments to dependencies, URL, sources, etc. If the revision number remains the same after such an update, but produces a resulting binary which is different, increasing the {{Codeline|pkgrel}} is mandatory. If both the revision number and the resulting binary remain the same, {{Codeline|pkgrel}} should be kept intact. There is no need to update the VCS package just to accommodate a revision bump, but one may choose to do so.
+
* When [[makepkg]] is run, by default it will check for newer revisions and then update the {{Ic|pkgver}} in the PKGBUILD. Look at {{Ic|--holdver}} in [http://www.archlinux.org/pacman/makepkg.8.html man makepkg] if you want otherwise.  {{Ic|--holdver}} only works for cvs and svn, which allow checkout of older revisions.
  
* When [[makepkg]] is run, by default it will check for newer revisions and then update the {{Codeline|pkgver}} in the PKGBUILDLook at {{Codeline|--holdver}} in [http://www.archlinux.org/pacman/makepkg.8.html man makepkg] if you want otherwise.  {{Codeline|--holdver}} only works for cvs and svn, which allow checkout of older revisions.
+
* Check for package conflictsFor example ''fluxbox-svn'' will conflict with ''fluxbox''. In this case, you need to use {{Ic|1=conflicts=('fluxbox')}}.
  
* Check for package conflicts.  For example ''fluxbox-svn'' will conflict with ''fluxbox''.  In this case, you need to use {{Codeline|1=conflicts=('fluxbox')}}.
+
* Use the {{Ic|provides}} field so that packages that require the non-VCS package can be installed ({{Ic|1=provides=('fluxbox')}}).
  
* Use the {{Codeline|provides}} field so that packages that require the non-VCS package can be installed ({{Codeline|1=provides=('fluxbox')}}).
+
* You should AVOID using {{Ic|1=replaces=...}} as it generally causes unnecessary problems.
  
* You should AVOID using {{Codeline|1=replaces=...}} as it generally causes unnecessary problems.
+
* When using/defining the cvsroot, use {{Ic|anonymous:@}} rather than {{Ic|anonymous@}} to avoid a password prompt and having to enter a blank password ''OR'' use {{Ic|anonymous:password@}} if a password is required.
  
* When using/defining the cvsroot, use {{Codeline|anonymous:@}} rather than {{Codeline|anonymous@}} to avoid a password prompt and having to enter a blank password ''OR'' use {{Codeline|anonymous:password@}} if a password is required.
+
* Don't forget to include the appropriate VCS tool (cvs, subversion, git, ...) in {{Ic|1=makedepends=...}}.
  
* Don't forget to include the appropriate VCS tool (cvs, subversion, git, ...) in {{Codeline|1=makedepends=...}}.
+
* To preserve the integrity of the checked-out code consider copying the original build directory if you have to make edits.  For example, having checked out source code to {{ic|src/$_cvsmod}} from {{ic|$startdir}} you can use:
 
+
* To preserve the integrity of the checked-out code consider copying the original build directory if you have to make edits.  For example, having checked out source code to {{Filename|src/$_cvsmod}} from {{Filename|$startdir}} you can use:
+
  
 
  mkdir src/$_cvsmod-build
 
  mkdir src/$_cvsmod-build
Line 48: Line 39:
 
  cd src/$_cvsmod-build
 
  cd src/$_cvsmod-build
  
* With the introduction of the [[AUR]], it is most important to avoid using backtick execution to create package variables. makepkg will automatically bump the {{Codeline|pkgver}} anyway when building the package (unless {{Codeline|--holdver}} is used).
+
* With the introduction of the [[AUR]], it is most important to avoid using backtick execution to create package variables. makepkg will automatically bump the {{Ic|pkgver}} anyway when building the package (unless {{Ic|--holdver}} is used).
  
 
== Tips ==
 
== Tips ==
 
 
* You should make sure that there are no VCS directories and files left over in your package. If there are, you may want to remove them, by adding a command similar to this one at the end of the the package() script:
 
* You should make sure that there are no VCS directories and files left over in your package. If there are, you may want to remove them, by adding a command similar to this one at the end of the the package() script:
  
  rm -rf `find "$pkgdir" -type d -name ".svn"`
+
  rm -rf $(find "$pkgdir" -type d -name ".svn")
  
* When using Git, one can speed up the cloning operation using the {{Codeline|1=--depth=1}} parameter. This creates a shallow clone, and has only the last change history - since histories are unimportant for builds most of the time.
+
* When using Git, one can speed up the cloning operation using the {{Ic|1=--depth=1}} parameter. This creates a shallow clone, and has only the last change history - since histories are unimportant for builds most of the time.
  
 
  git clone git://hostname.dom/project.git --depth=1
 
  git clone git://hostname.dom/project.git --depth=1
  
* It's possible to create the package also from a branch other than the master. To do so add {{Codeline|1=--branch branch_name}} after the first {{Codeline|1=git clone}}, in this way:
+
* It's possible to create the package also from a branch other than the master. To do so add {{Ic|1=--branch branch_name}} after the first {{Ic|1=git clone}}, in this way:
  
 
  git clone "$_gitroot" "$_gitname" --branch branch_name
 
  git clone "$_gitroot" "$_gitname" --branch branch_name
 +
Remember to save package with a different name, for example {{Ic|1= pkgname-branchname-git}}, in order to avoid confusion with the package from the branch master.
 +
 +
* Copy paste script when building from repo
 +
If you are lazy here is a sample script when making git-based PKGBUILDs.
 +
 +
  cd "$srcdir"
 +
  msg "Connecting to GIT server..."
 +
  if [ -d $_gitname ] ; then
 +
    cd $_gitname && git pull origin
 +
    msg "The local files are updated."
 +
  else
 +
    git clone --depth=1 $_gitroot $_gitname
 +
  fi
 +
  msg "GIT checkout done or server timeout"
 +
 +
* Temporary build directories: When using Git, and where you need to create a separate build directory (e.g., for building/compiling), you should avoid copying over the {{Ic|1=.git}} directory located in the parent folder because it contains history information that Git uses internally. With repos with thousands of commits, this .git directory will contain upwards of hundreds of MiB of useless commit history that has *nothing* to do with the current working tree. The only time you'd need to copy over the .git directory itself is when you need to build from a specific, older commit (which is generally never the case as the point of a VCS PKGBUILD is to pull from the latest bleeding edge commit). Thus, instead of
 +
 +
rm -rf "$srcdir/$_gitname-build"
 +
cp -R "$srcdir/$_gitname" "$srcdir/$_gitname-build" # copy everything, including the useless .git folder
 +
cd "$srcdir/$_gitname-build"
 +
make # build/compile from source
 +
 +
you should do
 +
 +
rm -rf "$srcdir/$_gitname-build"
 +
cd "$srcdir/$_gitname" && ls -A | grep -v .git | xargs -d '\n' cp -r -t ../$_gitname-build # do not copy over the .git folder
 +
cd "$srcdir/$_gitname-build"
 +
make # build/compile from source
 +
 +
to cut down on build time and disk usage.

Revision as of 09:28, 14 June 2012

Template:Package Guidelines

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

Prototypes

The ABS package provides prototypes for cvs, svn, git, mercurial, and darcs PKGBUILDs. When abs is installed, you can find them in /usr/share/pacman. Latest versions can be found in the prototypes directory in the ABS Git repository.

Guidelines

  • Properly suffix pkgname with -cvs, -svn, -hg, -darcs, -bzr, -git etc. If the package tracks a moving development trunk it should be given a suffix. If the package fetches a release from a VCS tag then it should not be given a suffix. Use this rule of thumb: if the output of the package depends on the time at which it was compiled, append a suffix; otherwise do not.
  • A VCS package may be updated as and when needed to adopt changes to the build system, including ammendments to dependencies, URL, sources, etc. If the revision number remains the same after such an update, but produces a resulting binary which is different, increasing the pkgrel is mandatory. If both the revision number and the resulting binary remain the same, pkgrel should be kept intact. There is no need to update the VCS package just to accommodate a revision bump, but one may choose to do so.
  • When makepkg is run, by default it will check for newer revisions and then update the pkgver in the PKGBUILD. Look at --holdver in man makepkg if you want otherwise. --holdver only works for cvs and svn, which allow checkout of older revisions.
  • Check for package conflicts. For example fluxbox-svn will conflict with fluxbox. In this case, you need to use conflicts=('fluxbox').
  • Use the provides field so that packages that require the non-VCS package can be installed (provides=('fluxbox')).
  • You should AVOID using replaces=... as it generally causes unnecessary problems.
  • When using/defining the cvsroot, use anonymous:@ rather than anonymous@ to avoid a password prompt and having to enter a blank password OR use anonymous:password@ if a password is required.
  • Don't forget to include the appropriate VCS tool (cvs, subversion, git, ...) in makedepends=....
  • To preserve the integrity of the checked-out code consider copying the original build directory if you have to make edits. For example, having checked out source code to src/$_cvsmod from $startdir you can use:
mkdir src/$_cvsmod-build

cd src/$_cvsmod-build
../$_cvsmod/configure

or:

cp -r src/$_cvsmod src/$_cvsmod-build
cd src/$_cvsmod-build
  • With the introduction of the AUR, it is most important to avoid using backtick execution to create package variables. makepkg will automatically bump the pkgver anyway when building the package (unless --holdver is used).

Tips

  • You should make sure that there are no VCS directories and files left over in your package. If there are, you may want to remove them, by adding a command similar to this one at the end of the the package() script:
rm -rf $(find "$pkgdir" -type d -name ".svn")
  • When using Git, one can speed up the cloning operation using the --depth=1 parameter. This creates a shallow clone, and has only the last change history - since histories are unimportant for builds most of the time.
git clone git://hostname.dom/project.git --depth=1
  • It's possible to create the package also from a branch other than the master. To do so add --branch branch_name after the first git clone, in this way:
git clone "$_gitroot" "$_gitname" --branch branch_name

Remember to save package with a different name, for example pkgname-branchname-git, in order to avoid confusion with the package from the branch master.

  • Copy paste script when building from repo

If you are lazy here is a sample script when making git-based PKGBUILDs.

 cd "$srcdir"
 msg "Connecting to GIT server..."
 if [ -d $_gitname ] ; then
   cd $_gitname && git pull origin
   msg "The local files are updated."
 else
   git clone --depth=1 $_gitroot $_gitname
 fi
 msg "GIT checkout done or server timeout"
  • Temporary build directories: When using Git, and where you need to create a separate build directory (e.g., for building/compiling), you should avoid copying over the .git directory located in the parent folder because it contains history information that Git uses internally. With repos with thousands of commits, this .git directory will contain upwards of hundreds of MiB of useless commit history that has *nothing* to do with the current working tree. The only time you'd need to copy over the .git directory itself is when you need to build from a specific, older commit (which is generally never the case as the point of a VCS PKGBUILD is to pull from the latest bleeding edge commit). Thus, instead of
rm -rf "$srcdir/$_gitname-build"
cp -R "$srcdir/$_gitname" "$srcdir/$_gitname-build" # copy everything, including the useless .git folder
cd "$srcdir/$_gitname-build"
make # build/compile from source

you should do

rm -rf "$srcdir/$_gitname-build"
cd "$srcdir/$_gitname" && ls -A | grep -v .git | xargs -d '\n' cp -r -t ../$_gitname-build # do not copy over the .git folder
cd "$srcdir/$_gitname-build"
make # build/compile from source

to cut down on build time and disk usage.