Difference between revisions of "Talk:Arch packaging standards"

From ArchWiki
Jump to: navigation, search
m (Clean the talk page)
m (Suggestions: more about .install files)
(28 intermediate revisions by 10 users not shown)
Line 5: Line 5:
 
* Shouldn't we suggest using SHA1 hash and not the already broken one (MD5)? [[User:Tomato|Tomato]] 15:47, 25 August 2010 (EDT)
 
* Shouldn't we suggest using SHA1 hash and not the already broken one (MD5)? [[User:Tomato|Tomato]] 15:47, 25 August 2010 (EDT)
 
* The section about custom variables ("_blah=blah") is misleading. Nowadays custom variables are a common practice since they can simplify and/or modularize the PKGBUILD a great deal. The parts where they are recommended to not to be used should be modified. --[[User:Det|Det]] 13:13, 14 September 2010 (EDT)
 
* The section about custom variables ("_blah=blah") is misleading. Nowadays custom variables are a common practice since they can simplify and/or modularize the PKGBUILD a great deal. The parts where they are recommended to not to be used should be modified. --[[User:Det|Det]] 13:13, 14 September 2010 (EDT)
 +
* I've recently found that packages that used bundles libraries tend to segfault. Should we suggest the removal of bundled libraries and instead use system libraries?
 +
* How about adding https://wiki.archlinux.org/index.php/Web_application_package_guidelines to the list? --[[User:Trontonic|Trontonic]] 11:18, 29 February 2012 (EST)
 +
* Something more should be said about .install files.  Mention that there are also examples in /usr/share/pacman but it also needs some explanation on how they work.
  
 
==Proposed revision (shouldn't this already be added...?)==
 
==Proposed revision (shouldn't this already be added...?)==
 
+
====Directories====
===Packaging Standards===
+
Is something like /usr/include/{pkg} allowed?
The submitted PKGBUILDs <b>must not</b> build applications already in any of the official binary repositories under any circumstances. Exception to this strict rule may only be packages being newer or having extra features enabled and/or patches in compar<b>ison with the</b> official ones. In such occasions, the pkgname array should be different <s>to express that difference</s>.
+
Is something like /usr/lib/{pkg}-{versionnumber} allowed? Same for /usr/share?
 
 
When building packages for <b>the AUR</b>, <s>you should </s> adhere to the package guidelines below, especially if <s>you would like</s> <b>the intention is</b> to contribute <b>a</b> <s>your new</s> package to Arch Linux.
 
 
 
...
 
====PKGBUILD Prototype====
 
Should really tell the user that prototypes are in /usr/share/pacman from the pacman and abs packages. Maybe also a newpkg (pkgtools) mention.
 
 
 
 
 
# Contributor: <s>Your</s> Name <b>email</b> at domain dot com> (disguise <s>your</s> email...
 
  
 
====Package Etiquette====
 
====Package Etiquette====
  
...<br>
 
Do not introduce new variables into <s>your</s> PKGBUILD build scripts ...
 
 
The AUR cannot detect the use of custom variables and so canno ... This can most often be seen in the source array<b>, e.g.:</b>
 
  
 
...<br>
 
...<br>
 
file, or alternatively by exporting the PACKAGER environment variable before building packages with makepkg:
 
file, or alternatively by exporting the PACKAGER environment variable before building packages with makepkg:
 
  <b>$</b> export PACKAGER="John Doe@<b>email</b>"
 
  <b>$</b> export PACKAGER="John Doe@<b>email</b>"
 +
 +
====Architectures====
  
 
...<br>
 
...<br>
The above example is taken from the wine package in extra. The optdepends information will automatically be printed out on installation/upgrade<b>.</b><s> from pacman 3.2.1, so one should not keep this kind of information in .install files any longer.</s>
+
depending on which architectures it can be built on. <s>You can also use</s> <b>State</b> 'any' for architecture independent packages.
  
 
...
 
...
====Package Naming====
+
====Licenses====
  
...<br>
 
Version tags may not include hyphens<b>.</b> Letters, numbers, and periods only.
 
  
...<br>
+
*Add 'custom' to the licenses array.  Optionally, <s>you can</s> replace 'custom' with 'custom:"name of license"'.
the package will be re-released to the AL <b>(???)</b> public and
 
 
 
...
 
====Directories====
 
  
 
...<br>
 
...<br>
Use /etc/{pkgname}/  where {pkgname} is the name of <b>the</b> package
+
When pacman gets the ability to filter on licenses (<b>i.e., make pacman download only GPL and BSD licensed software"</b>) dual (or more) licenses will be treated by pacman using ''''or'''', rather than ''''and'''' logic, thus pacman will consider ...
  
...
+
====Submitting Packages to the AUR====
====Makepkg Duties====
 
  
...<br>
+
<s>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.</s> <i>This gets repeated word for word in [[#Packaging Standards]]</i>
When makepkg <b>is used</b> to build a package <s>for you</s>, it does the following automatically:
 
  
...
+
- I see no problem in repeating it here as regularly there are users not following that rule. [[User:Snowman|Snowman]]
====Architectures====
 
  
...<br>
 
depending on which architectures it can be built on. <s>You can also use</s> <b>State</b> 'any' for architecture independent packages.
 
  
...
 
====Licenses====
 
  
 
...<br>
 
...<br>
The license array is being implemented little by little in the official repos, and it <b>should</b> be used in <b>AUR</b> packages as well. <s>You can </s> <b>U</b>se it as follows:
+
To ensure the security of pkgs submitted to the AUR please ensure that <b>the md5sum values</b> have <b>been</b> correctly filled. The md5sum's can b...
  
*If the source tarball does <b>not</b> contain the license details and the license is only displayed on a website for example, then <s>you need to</s> copy the licen...
+
===Additional Guidelines===
 +
Be sure to read the above guidelines first'''--''' important points are listed on this page that will not be repeated in the following guideline pages...
  
*Add 'custom' to the licenses array. Optionally, <s>you can</s> replace 'custom' with 'custom:"name of license"'.
+
===Package Releases===
 +
Package releases are specific to Arch Linux packages. These allow users to differentiate between newer and older package builds. When a new package version is first released, the release count starts at 1. Then as fixes and optimizations are made, the package will be re-released to the Arch Linux public and the release number will increment. When a new version comes out, the release count resets to 1. Package release tags follow the same naming restrictions as version tags.
  
...<br>
+
Examples of when to change the package release number:
When pacman gets the ability to filter on licenses (<b>i.e., make pacman download only GPL and BSD licensed software"</b>) dual (or more) licenses will be treated by pacman using ''''or'''', rather than ''''and'''' logic, thus pacman will consider ...
 
  
====Submitting Packages to the AUR====
+
* Changing pkgdesc -> do NOT bump (unless it is severely wrong or something)
 +
* Changing deps -> bump
 +
* Changing makedeps -> do NOT bump, ever
 +
* Changing optdeps -> do NOT bump (unless very important functionality provided)
 +
* Changing build stuff (i.e changing PKGBUILD but no change to resulting binary) -> do NOT bump
  
<s>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.</s> <i>This gets repeated word for word in [[#Packaging Standards]]</i>
+
(based on aur-general discussion: https://mailman.archlinux.org/pipermail/aur-general/2011-April/014247.html)
  
...<br>
+
===Adding system users===
To ensure the security of pkgs submitted to the AUR please ensure that <b>the md5sum values</b> have <b>been</b> correctly filled.  The md5sum's can b...
 
  
...<br>
+
Some packages require the addition of system users. For them to be ignored by things such as lightdm, tthey have to be in the sub-1000 UID space. Looking at packages in ABS, these users are simply added with an <tt>useradd -u ...</tt>. However, there is no guideline or authoritative list that I can find which lists which UID is used for what, which is free, or how to register a UID for a specific system user. It would be nice to see a section about it here.
Please add a comment line to the top of <b>the</b> PKGBUILD file that follows this format. Remembe...  
 
  
...
+
--[[User:OlivierMehani|OlivierMehani]] 19:31, 13 October 2011 (EDT)
# Contributor: <s>Your</s> Name <address at domain dot com></pre>
 
 
recommend the use of the namcap <b>package</b>, written by Jason Chu (jason@archlinux.org), to analyze the sanity of <s>your</s> packages. namcap will <s>tell you</s> <b>warn</b> about bad permissions, missing dependencies, un-needed dependencies, and other common mistakes. <s>You can install the namcap package</s> by...
 
  
...<br>
+
See https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database
Don't use replaces in <b>a</b> PKGBUILD unless <b>the package is to be renamed</b>, for example when ''Ethereal'' became ''Wireshark''. If <b>the package is</b> an alternate version of an already existing package, use conflicts (and provides if that package is required by others). The main difference is: after syncing (-Sy) pacman immediately wants to replace an installed, 'offending' package upon encountering a package with the matching replaces anywhere in its repositories; conflicts on the other hand is only evaluated when actually installing the package, which is <b>usually</b> the desired behavior because <b>it is less invasive.</b>
 
  
...<br>
+
I thinks it's a bit too specific to be listed here.
<b>One</b> can easily build a tarball containing all the required files by using makepkg --source. This
 
makes a tarball named $pkgname-$pkgver-$pkgrel.src.tar.gz, which <s>you</s> can then <b>be</b> upload<b>ed</b> to the AUR.
 
  
...
+
[[User:Snowman|Snowman]] 20:45, 13 October 2011 (EDT)
===Additional Guidelines===
 
Be sure to read the above guidelines first'''--''' important points are listed on this page that will not be repeated in the following guideline pages...
 

Revision as of 23:30, 14 October 2012

Comments

  • What encoding (ascii ? UTF-8 ?) should be used for text files in submitted packages ? --Airbag 13:43, 15 August 2006 (PDT)

Suggestions

  • Shouldn't we suggest using SHA1 hash and not the already broken one (MD5)? Tomato 15:47, 25 August 2010 (EDT)
  • The section about custom variables ("_blah=blah") is misleading. Nowadays custom variables are a common practice since they can simplify and/or modularize the PKGBUILD a great deal. The parts where they are recommended to not to be used should be modified. --Det 13:13, 14 September 2010 (EDT)
  • I've recently found that packages that used bundles libraries tend to segfault. Should we suggest the removal of bundled libraries and instead use system libraries?
  • How about adding https://wiki.archlinux.org/index.php/Web_application_package_guidelines to the list? --Trontonic 11:18, 29 February 2012 (EST)
  • Something more should be said about .install files. Mention that there are also examples in /usr/share/pacman but it also needs some explanation on how they work.

Proposed revision (shouldn't this already be added...?)

Directories

Is something like /usr/include/{pkg} allowed? Is something like /usr/lib/{pkg}-{versionnumber} allowed? Same for /usr/share?

Package Etiquette

...
file, or alternatively by exporting the PACKAGER environment variable before building packages with makepkg:

$ export PACKAGER="John Doe@email"

Architectures

...
depending on which architectures it can be built on. You can also use State 'any' for architecture independent packages.

...

Licenses

  • Add 'custom' to the licenses array. Optionally, you can replace 'custom' with 'custom:"name of license"'.

...
When pacman gets the ability to filter on licenses (i.e., make pacman download only GPL and BSD licensed software") dual (or more) licenses will be treated by pacman using 'or', rather than 'and' logic, thus pacman will consider ...

Submitting Packages to the AUR

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. This gets repeated word for word in #Packaging Standards

- I see no problem in repeating it here as regularly there are users not following that rule. Snowman


...
To ensure the security of pkgs submitted to the AUR please ensure that the md5sum values have been correctly filled. The md5sum's can b...

Additional Guidelines

Be sure to read the above guidelines first-- important points are listed on this page that will not be repeated in the following guideline pages...

Package Releases

Package releases are specific to Arch Linux packages. These allow users to differentiate between newer and older package builds. When a new package version is first released, the release count starts at 1. Then as fixes and optimizations are made, the package will be re-released to the Arch Linux public and the release number will increment. When a new version comes out, the release count resets to 1. Package release tags follow the same naming restrictions as version tags.

Examples of when to change the package release number:

  • Changing pkgdesc -> do NOT bump (unless it is severely wrong or something)
  • Changing deps -> bump
  • Changing makedeps -> do NOT bump, ever
  • Changing optdeps -> do NOT bump (unless very important functionality provided)
  • Changing build stuff (i.e changing PKGBUILD but no change to resulting binary) -> do NOT bump

(based on aur-general discussion: https://mailman.archlinux.org/pipermail/aur-general/2011-April/014247.html)

Adding system users

Some packages require the addition of system users. For them to be ignored by things such as lightdm, tthey have to be in the sub-1000 UID space. Looking at packages in ABS, these users are simply added with an useradd -u .... However, there is no guideline or authoritative list that I can find which lists which UID is used for what, which is free, or how to register a UID for a specific system user. It would be nice to see a section about it here.

--OlivierMehani 19:31, 13 October 2011 (EDT)

See https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database

I thinks it's a bit too specific to be listed here.

Snowman 20:45, 13 October 2011 (EDT)