Difference between revisions of "Talk:Arch packaging standards"

From ArchWiki
Jump to: navigation, search
(Submitting Packages to the AUR)
(Remove outdated conversation.)
(46 intermediate revisions by 17 users not shown)
Line 1: Line 1:
==Comments==
 
* What encoding (ascii ? UTF-8 ?) should be used for text files in submitted packages ? --[[User:Airbag|Airbag]] 13:43, 15 August 2006 (PDT)
 
 
 
==Suggestions==
 
==Suggestions==
* 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)
+
 
+
==Proposed revision (shouldn't this already be added...?)==
+
 
+
====Package Etiquette====
+
  
 +
:My packages contain both {{ic|md5sums}} and {{ic|sha256sums}} arrays. I do so on the theory that some clients may not have the sha256sum utility installed, and those clients can fall back to the md5sum utility. Clarification would be appreciated. [[User:Ichimonji10|Ichimonji10]] ([[User talk:Ichimonji10|talk]]) 14:32, 19 October 2013 (UTC)
  
...<br>
+
::All of the shaXsum programs are provided by {{Pkg|coreutils}}, which is part of the {{Grp|base}} group. If a user doesn't have coreutils installed, they will have a ''very'' broken system.
file, or alternatively by exporting the PACKAGER environment variable before building packages with makepkg:
+
::In short, you don't need to provide more than one checksum array, and to be more secure, you should use one of the SHA-1 or SHA-2 checksums.
<b>$</b> export PACKAGER="John Doe@<b>email</b>"
+
::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 05:38, 10 December 2013 (UTC)
  
====Architectures====
+
:::That makes loads of sense, and I'll update my packages accordingly. Thank you. Uh... could you (or some other wiki maintainer) update this article to reference, say, {{ic|sha256sum}} instead of {{ic|md5sum}}?
 +
:::[[User:Ichimonji10|Ichimonji10]] ([[User talk:Ichimonji10|talk]]) 15:29, 10 December 2013 (UTC)
  
...<br>
+
----
depending on which architectures it can be built on. <s>You can also use</s> <b>State</b> 'any' for architecture independent packages.
+
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? --[[User:Gadget3000|Gadget3000]] ([[User_talk:Gadget3000|talk]]) 02:13, 6 August 2011 (UTC)
  
...
+
----
====Licenses====
+
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. --[[User:OlivierMehani|OlivierMehani]] 19:31, 13 October 2011 (EDT)
  
 +
:See [[DeveloperWiki:UID_/_GID_Database]].
  
*Add 'custom' to the licenses array. Optionally, <s>you can</s> replace 'custom' with 'custom:"name of license"'.
+
:I thinks it's a bit too specific to be listed here. --[[User:Snowman|Snowman]] 20:45, 13 October 2011 (EDT)
  
...<br>
+
----
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 ...
+
How about adding [[Web_application_package_guidelines]] to the list? --[[User:Trontonic|Trontonic]] 11:18, 29 February 2012 (EST)
  
====Submitting Packages to the AUR====
+
----
 +
Something more should be said about .install files.  Mention that there are also examples in {{ic|/usr/share/pacman}} but it also needs some explanation on how they work. --[[User:Mauro2|Mauro2]] ([[User_talk:Mauro2|talk]]) 05:30, 15 October 2012 (UTC)
  
<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]]
+
Please remove the {{ic|cd "$srcdir..."}} no-op from the examples on the page. See: https://bugs.archlinux.org/task/34314 --[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 20:55, 14 March 2013 (UTC)
  
 +
----
 +
[[Arch_Packaging_Standards#Package_etiquette]] states: "It is common practice to preserve the order of the PKGBUILD fields as shown above." But this is not true. Common practice is to use {{ic|/usr/share/pacman/PKGBUILD.proto}} as a template, and the order of fields in that prototype has a far greater influence on packages in the wild than this page. This page should edited to reflect the current state of {{ic|PKGBUILD.proto}}. Perhaps this page should state: "It is common practice to order PKGBUILD fields so they match the order of fields in {{ic|PKGBUILD.proto}}. [[User:Ichimonji10|Ichimonji10]] ([[User talk:Ichimonji10|talk]]) 14:32, 19 October 2013 (UTC)
  
 +
== /usr/sbin -> /usr/bin merge ==
  
...<br>
+
The Directories section needs to be updated to reflect the recent /bin, /sbin, /usr/sbin -> /usr/bin merge:
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...
+
* <s>The /usr/sbin line should be removed and the description of the /usr/bin line should be changed to all binaries or something similar.</s>
 +
* /bin and /sbin should be added to the "Package should not contain following directories" list.
 +
-- [[User:Kyrias|Kyrias]] ([[User talk:Kyrias|talk]]) 15:00, 6 June 2013 (UTC)
  
...
+
:The first point was fixed months ago in [https://wiki.archlinux.org/index.php?title=Arch_Packaging_Standards&diff=264065&oldid=237808], so I crossed that off the list.
# Contributor: <s>Your</s> Name <address at domain dot com></pre>
+
:The second point still needs to be fixed.
+
:-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 05:33, 10 December 2013 (UTC)
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>
+
== Punctuation in PKGBUILD ==
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>
+
What is the official guidance regarding ending a pkgdesc in a period or using commas and English prose punctuation in general?
  
...<br>
+
[[https://bbs.archlinux.org/viewtopic.php?pid=1288063 Link]] to discussion thread.
<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:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 15:17, 14 June 2013 (UTC)
  
===Additional Guidelines===
+
== There should be a clearly visible link to "Creating packages" page ==
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 ==
+
Please, move the block located in the bottom of this page to its top. [[User:Eigrad|Andrew Grigorev]] ([[User talk:Eigrad|talk]]) 19:21, 17 July 2013 (UTC)
  
It would be helpful if the wiki gave explicit instructions on how to do this, eg
+
== Proposed new package naming ==
  
  install -D -m644 LICENSE $pkgdir/usr/share/licenses/${pkgname}/LICENSE
+
==Package naming==
 +
* 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 versions '''should be the same as the version released by the author'''. Versions can include letters if need be (eg, nmap's version is 2.54BETA32). '''Version tags may not include hyphens!''' Letters, numbers, and periods only.
 +
* 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'''.

Revision as of 20:42, 16 December 2013

Suggestions

Shouldn't we suggest using SHA1 hash and not the already broken one (MD5)? --Tomato 15:47, 25 August 2010 (EDT)

My packages contain both md5sums and sha256sums arrays. I do so on the theory that some clients may not have the sha256sum utility installed, and those clients can fall back to the md5sum utility. Clarification would be appreciated. Ichimonji10 (talk) 14:32, 19 October 2013 (UTC)
All of the shaXsum programs are provided by coreutils, which is part of the base group. If a user doesn't have coreutils installed, they will have a very broken system.
In short, you don't need to provide more than one checksum array, and to be more secure, you should use one of the SHA-1 or SHA-2 checksums.
-- Jstjohn (talk) 05:38, 10 December 2013 (UTC)
That makes loads of sense, and I'll update my packages accordingly. Thank you. Uh... could you (or some other wiki maintainer) update this article to reference, say, sha256sum instead of md5sum?
Ichimonji10 (talk) 15:29, 10 December 2013 (UTC)

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? --Gadget3000 (talk) 02:13, 6 August 2011 (UTC)


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 DeveloperWiki:UID_/_GID_Database.
I thinks it's a bit too specific to be listed here. --Snowman 20:45, 13 October 2011 (EDT)

How about adding 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. --Mauro2 (talk) 05:30, 15 October 2012 (UTC)


Please remove the cd "$srcdir..." no-op from the examples on the page. See: https://bugs.archlinux.org/task/34314 --Graysky (talk) 20:55, 14 March 2013 (UTC)


Arch_Packaging_Standards#Package_etiquette states: "It is common practice to preserve the order of the PKGBUILD fields as shown above." But this is not true. Common practice is to use /usr/share/pacman/PKGBUILD.proto as a template, and the order of fields in that prototype has a far greater influence on packages in the wild than this page. This page should edited to reflect the current state of PKGBUILD.proto. Perhaps this page should state: "It is common practice to order PKGBUILD fields so they match the order of fields in PKGBUILD.proto. Ichimonji10 (talk) 14:32, 19 October 2013 (UTC)

/usr/sbin -> /usr/bin merge

The Directories section needs to be updated to reflect the recent /bin, /sbin, /usr/sbin -> /usr/bin merge:

  • The /usr/sbin line should be removed and the description of the /usr/bin line should be changed to all binaries or something similar.
  • /bin and /sbin should be added to the "Package should not contain following directories" list.

-- Kyrias (talk) 15:00, 6 June 2013 (UTC)

The first point was fixed months ago in [1], so I crossed that off the list.
The second point still needs to be fixed.
-- Jstjohn (talk) 05:33, 10 December 2013 (UTC)

Punctuation in PKGBUILD

What is the official guidance regarding ending a pkgdesc in a period or using commas and English prose punctuation in general?

[Link] to discussion thread.

Graysky (talk) 15:17, 14 June 2013 (UTC)

There should be a clearly visible link to "Creating packages" page

Please, move the block located in the bottom of this page to its top. Andrew Grigorev (talk) 19:21, 17 July 2013 (UTC)

Proposed new package naming

Package naming

  • 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 versions should be the same as the version released by the author. Versions can include letters if need be (eg, nmap's version is 2.54BETA32). Version tags may not include hyphens! Letters, numbers, and periods only.
  • 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.