Talk:Arch packaging standards

From ArchWiki
Revision as of 13:03, 8 April 2011 by Haawda (talk | contribs) (Proposed revision (shouldn't this already be added...?))
Jump to: navigation, search


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


  • 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)

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


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"


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



  • 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's 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: