Difference between revisions of "Talk:Arch packaging standards"

From ArchWiki
Jump to: navigation, search
(Submitting Packages to the AUR)
(Submitting Packages to the AUR)
Line 33: Line 33:
 
<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>
 
<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>
  
I see no problem in repeating it here as regularly there are users not following that rule. [[User:Snowman|Snowman]]
+
- I see no problem in repeating it here as regularly there are users not following that rule. [[User:Snowman|Snowman]]
  
  

Revision as of 03:02, 3 January 2011

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)

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

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...

...

# Contributor: Your Name <address at domain dot com></pre>

recommend the use of the namcap package, written by Jason Chu (jason@archlinux.org), to analyze the sanity of your packages. namcap will tell you warn about bad permissions, missing dependencies, un-needed dependencies, and other common mistakes. You can install the namcap package by...

...
Don't use replaces in a PKGBUILD unless the package is to be renamed, for example when Ethereal became Wireshark. If the package is 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 usually the desired behavior because it is less invasive.

...
One 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 you can then be uploaded to the AUR.

...

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...

License installing

It would be helpful if the wiki gave explicit instructions on how to do this, eg

  install -D -m644 LICENSE $pkgdir/usr/share/licenses/${pkgname}/LICENSE