Difference between revisions of "Manjaro Packaging Standards"

__TOC__

__TOC__

<translate>

<translate>

'''The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Exception to this strict rule may only be packages having extra features enabled and/or patches in comparison to the official ones. In such an occasion, the pkgname array should be different.'''

'''The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Exception to this strict rule may only be packages having extra features enabled and/or patches in comparison to the official ones. In such an occasion, the pkgname array should be different.'''

When building packages for Manjaro Linux, '''adhere to the package guidelines''' below, especially if the intention is

When building packages for Manjaro Linux, '''adhere to the package guidelines''' below, especially if the intention is

to '''contribute''' a new package

to '''contribute''' a new package

</translate>

</translate>

<translate>

<translate>

{{bc|1=

{{bc|1=

# Maintainer: Your Name <youremail@domain.com>

# Maintainer: Your Name <youremail@domain.com>

md5sums=() #autofill using updpkgsums

md5sums=() #autofill using updpkgsums

build() {

build() {

   cd $pkgname-$pkgver

   cd $pkgname-$pkgver

   make

   make

}

}

package() {

package() {

   cd $pkgname-$pkgver

   cd $pkgname-$pkgver

}

}

}}

}}

Other prototypes are found in {{ic|/usr/share/pacman}} from the pacman and abs packages.

Other prototypes are found in {{ic|/usr/share/pacman}} from the pacman and abs packages.

</translate>

</translate>

<translate>

<translate>

<li>Packages should '''never''' be installed to {{ic|/usr/local}}</li>

<li>Packages should '''never''' be installed to {{ic|/usr/local}}</li>

<li>

<li>

in makepkg itself.

in makepkg itself.

'''prefix the variable name with an underscore''' ({{ic|_}}), e.g.

'''prefix the variable name with an underscore''' ({{ic|_}}), e.g.

{{bc|1=_customvariable=}}

{{bc|1=_customvariable=}}

{{bc|<nowiki>http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2</nowiki>}}

{{bc|<nowiki>http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2</nowiki>}}

Such a situation defeats the effective functionality of the AUR.

Such a situation defeats the effective functionality of the AUR.

</li>

</li>

'''Avoid''' using {{ic|/usr/libexec/}} for

'''Avoid''' using {{ic|/usr/libexec/}} for

anything. Use {{ic|/usr/lib/${pkgname}/}} instead.

anything. Use {{ic|/usr/lib/${pkgname}/}} instead.

the appropriate option in the {{ic|/etc/makepkg.conf}}

the appropriate option in the {{ic|/etc/makepkg.conf}}

<li>

<li>

All important messages should be echoed during install using an '''.install file'''. For

All important messages should be echoed during install using an '''.install file'''. For

}}

}}

The above example is taken from the <b>wine</b> package in {{Ic|extra}}. The optdepends

The above example is taken from the <b>wine</b> package in {{Ic|extra}}. The optdepends

information is automatically printed out on installation/upgrade so

information is automatically printed out on installation/upgrade so

one should <b>not</b> keep this kind of information in .install files.

one should <b>not</b> keep this kind of information in .install files.

</li>

</li>

         <li>When creating a '''package description''' for a package, do not include

         <li>When creating a '''package description''' for a package, do not include

</translate>

</translate>

<translate>

<translate>

* Package names should consist of '''alphanumeric characters only'''; all letters should be '''lowercase'''.

* Package names should consist of '''alphanumeric characters only'''; all letters should be '''lowercase'''.

* Package names should NOT be suffixed with the upstream major release version number (e.g. we don't want libfoo2 if upstream calls it libfoo v2.3.4) in case the library and its dependencies are expected to be able to keep using the most recent library version with each respective upstream release. However, for some software or dependencies, this can not be assumed. In the past this has been especially true for widget toolkits such as GTK and Qt. Software that depends on such toolkits can usually not be trivially ported to a new major version. As such, in cases where software can not trivially keep rolling alongside its dependencies, package names should carry the major version suffix (e.g. gtk2, gtk3, qt4, qt5). For cases where most dependencies can keep rolling along the newest release but some can't (for instance closed source that needs libpng12 or similar), a deprecated version of that package might be called libfoo1 while the current version is just libfoo.

* Package names should NOT be suffixed with the upstream major release version number (e.g. we don't want libfoo2 if upstream calls it libfoo v2.3.4) in case the library and its dependencies are expected to be able to keep using the most recent library version with each respective upstream release. However, for some software or dependencies, this can not be assumed. In the past this has been especially true for widget toolkits such as GTK and Qt. Software that depends on such toolkits can usually not be trivially ported to a new major version. As such, in cases where software can not trivially keep rolling alongside its dependencies, package names should carry the major version suffix (e.g. gtk2, gtk3, qt4, qt5). For cases where most dependencies can keep rolling along the newest release but some can't (for instance closed source that needs libpng12 or similar), a deprecated version of that package might be called libfoo1 while the current version is just libfoo.

</translate>

</translate>

<translate>

<translate>

* '''Configuration files''' should be placed in the {{ic|/etc}} directory. If there is more than one configuration file, it is customary to '''use a subdirectory''' in order to keep the {{ic|/etc}} area as clean as possible. Use {{ic|/etc/{pkgname}/}}  where {{ic|<nowiki>{pkgname}</nowiki>}} is the name of the package (or a suitable alternative, eg, apache uses {{ic|/etc/httpd/}}).

* '''Configuration files''' should be placed in the {{ic|/etc}} directory. If there is more than one configuration file, it is customary to '''use a subdirectory''' in order to keep the {{ic|/etc}} area as clean as possible. Use {{ic|/etc/{pkgname}/}}  where {{ic|<nowiki>{pkgname}</nowiki>}} is the name of the package (or a suitable alternative, eg, apache uses {{ic|/etc/httpd/}}).

* Package files should follow these '''general directory guidelines''':

* Package files should follow these '''general directory guidelines''':

:{|

:{|

|-

|-

|}

|}

* Packages should not contain any of the following directories:

* Packages should not contain any of the following directories:

** {{ic|/dev}}

** {{ic|/dev}}

</translate>

</translate>

<translate>

<translate>

When [[makepkg]] is used to build a package, it does the

When [[makepkg]] is used to build a package, it does the

following automatically:

following automatically:

</p>

</p>

<li>

<li>

Checks if package '''dependencies''' and '''makedepends''' are installed

Checks if package '''dependencies''' and '''makedepends''' are installed

<li>

<li>

root

root

</li>

</li>

</li>

</li>

'''Compresses''' the fake root into the package file

'''Compresses''' the fake root into the package file

</li>

</li>

</li>

</li>

</translate>

</translate>

<translate>

<translate>

The {{Ic|arch}} array should contain {{Ic|'i686'}} and/or {{Ic|'x86_64'}} depending on which architectures it can be built on. You can also use {{Ic|'any'}} for architecture independent packages.

The {{Ic|arch}} array should contain {{Ic|'i686'}} and/or {{Ic|'x86_64'}} depending on which architectures it can be built on. You can also use {{Ic|'any'}} for architecture independent packages.

</translate>

</translate>

<translate>

<translate>

The [[Licenses|license]] array is being implemented in the official repos, and it <b>should</b> be used in your packages as well. Use it as follows:

The [[Licenses|license]] array is being implemented in the official repos, and it <b>should</b> be used in your packages as well. Use it as follows:

<ul>

<ul>

</translate>

</translate>

<translate>

<translate>

<p>Note the following before submitting any packages to the AUR:</p>

<p>Note the following before submitting any packages to the AUR:</p>

         <li>

         <li>

                 The submitted PKGBUILDs '''MUST NOT''' build applications already in any of the official binary repositories under any circumstances. Exception to this strict rule may only be packages having extra features enabled and/or patches in compare to the official ones. In such an occasion the pkgname array should be different to express that difference.

                 The submitted PKGBUILDs '''MUST NOT''' build applications already in any of the official binary repositories under any circumstances. Exception to this strict rule may only be packages having extra features enabled and/or patches in compare to the official ones. In such an occasion the pkgname array should be different to express that difference.

                 your email to protect against spam:

                 your email to protect against spam:

{{bc|# Maintainer: Your Name <address at domain dot com>}}

{{bc|# Maintainer: Your Name <address at domain dot com>}}

If you are assuming the role of maintainer for an existing PKGBUILD, add your name to the top as described above and change the title of the previous Maintainer(s) to Contributor:

If you are assuming the role of maintainer for an existing PKGBUILD, add your name to the top as described above and change the title of the previous Maintainer(s) to Contributor:

{{bc|# Maintainer: Your Name <address at domain dot com>

{{bc|# Maintainer: Your Name <address at domain dot com>

# Contributor: Previous Name <address at domain dot com>}}

# Contributor: Previous Name <address at domain dot com>}}

<li>

<li>

Verify the package '''dependencies''' (eg, run

Verify the package '''dependencies''' (eg, run

by scripts, etc).

by scripts, etc).

{{ic|namcap}} utility, written by Jason Chu (jason@archlinux.org), to analyze the

{{ic|namcap}} utility, written by Jason Chu (jason@archlinux.org), to analyze the

sanity of packages. {{ic|namcap}} will warn you about

sanity of packages. {{ic|namcap}} will warn you about

{{ic|namcap}} package with {{ic|pacman}}.

{{ic|namcap}} package with {{ic|pacman}}.

</li>

</li>

<li> '''Dependencies'''

<li> '''Dependencies'''

e.g. foo.tar.gz.

e.g. foo.tar.gz.

One can easily build a tarball containing all the required files by using {{Ic|makepkg --source}}. This

One can easily build a tarball containing all the required files by using {{Ic|makepkg --source}}. This

makes a tarball named {{Ic|$pkgname-$pkgver-$pkgrel.src.tar.gz}}, which can then be uploaded to the AUR.

makes a tarball named {{Ic|$pkgname-$pkgver-$pkgrel.src.tar.gz}}, which can then be uploaded to the AUR.

</li>

</li>

</translate>

</translate>

[[Category:Contents Page{{#translation:}}]]

[[Category:Contents Page{{#translation:}}]]