Difference between revisions of "Talk:Arch packaging standards"

From ArchWiki
Jump to: navigation, search
(Suggestions: Fix typo.)
(Add security standards: edit)
 
(98 intermediate revisions by 26 users not shown)
Line 1: Line 1:
==Suggestions==
+
== Fields order ==
Shouldn't we suggest using SHA1 hash and not the already broken one (MD5)? --[[User:Tomato|Tomato]] 15:47, 25 August 2010 (EDT)
 
  
: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)
+
[[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)
  
----
+
== Punctuation in PKGBUILD ==
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)
+
What is the official guidance regarding ending a pkgdesc in a period or using commas and English prose punctuation in general?
  
----
+
[[https://bbs.archlinux.org/viewtopic.php?pid=1288063 Link]] to discussion thread.
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]].
+
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 15:17, 14 June 2013 (UTC)
  
:I thinks it's a bit too specific to be listed here. --[[User:Snowman|Snowman]] 20:45, 13 October 2011 (EDT)
+
==Package naming==
 +
* Package names should consist of '''alphanumeric characters only'''; all letters should be '''lowercase'''.
 +
:--unsigned
  
----
+
::This is a guideline, but I see some packages with hypens and underscores (tesseract-data-chi_sim), dots (gstreamer0.10), plus (libxml++) and even at-signs (kde-l10n-ca@valencia). A package with uppercase name is libreoffice-bn-IN. According to the makepkg source, the allowed chars are: {{ic|[:alnum:]+_.@-}}. [[User:Lekensteyn|Lekensteyn]] ([[User talk:Lekensteyn|talk]]) 22:38, 1 February 2014 (UTC)
How about adding [[Web_application_package_guidelines]] to the list? --[[User:Trontonic|Trontonic]] 11:18, 29 February 2012 (EST)
 
  
----
+
:::"alphanumeric characters only" rule is ridiculous, 85% of official packages break this rule. I think it should be changed to allow hypens. It makes package names more readable. In regards to other characters, the + sign breaks [https://aur.archlinux.org/rpc.php AUR search] ([https://aur.archlinux.org/rpc.php?type=search&arg=a++ example], [https://aur.archlinux.org/rpc.php?type=search&arg=a%2B%2B should be escaped]). [[User:Axper|axper]] ([[User talk:Axper|talk]]) 11:19, 11 May 2014 (UTC)
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)
 
  
----
+
* 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.
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)
+
:--unsigned
  
----
+
* 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.
{{ic|makepkg -g}} has been superseded by {{ic|updpkgsums}} since [http://allanmcrae.com/2013/04/pacman-4-1-released/ pacman 4.1], which doesn't require redirection operators ({{ic|>>}}) or removing the earlier md5sums (with something like {{ic|sed -i "/md5sums/,/)/d" PKGBUILD}}). --[[User:Det|Det]] ([[User talk:Det|talk]]) 12:16, 7 April 2013 (UTC)
+
:--unsigned
  
:I second Det's request: add this to the wiki. {{ic|updpkgsums}} is nicer than {{ic|makepkg -g}}, and the existence of such a tool should be promulgated. I didn't even know about the tool until reading through this discussion page. [[User:Ichimonji10|Ichimonji10]] ([[User talk:Ichimonji10|talk]]) 14:32, 19 October 2013 (UTC)
+
::This rule needs to get more stricter. Having a slash in the version breaks filenames. For craziness, I tried setting up a pkgver containing all characters from 0x01 to 0xff which makes makepkg throw a Bash syntax error. The current packages have versions matching {{ic}[[alnum:]._+~]+} (and a colon for epoch, a hypen for pkgrel). What about limiting to those characters? Debian has a similar set, see [https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version their policy docs] [[User:Lekensteyn|Lekensteyn]] ([[User talk:Lekensteyn|talk]]) 22:38, 1 February 2014 (UTC)
  
----
+
* 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'''.
[[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)
+
:--unsigned
 +
 
 +
* Why is there no mentioning of suffixes for different build sources, such as vcs sources (-git, -hg, …) or binary distributions (-bin)? IMO this is an important part of the package naming conventions in AUR. [[User:Fordprefect|Fordprefect]] ([[User talk:Fordprefect|talk]]) 13:43, 10 May 2016 (UTC)
 +
 
 +
== Is it acceptable for build() to start by removing directories? ==
 +
 
 +
I just downloaded a PKGBUILD whose build() function begins with the following:
 +
 
 +
find ./ -maxdepth 1 -mindepth 1 -type d  -exec rm -r {} \;
 +
 
 +
It seems to me that a PKGBUILD has no business doing this and that it is potentially dangerous. I admit that its danger will typically require people to do non-standard things and, arguably, things they would be better advised not to do anyway. But it still seems to me to invite trouble.
 +
 
 +
I don't remember seeing this in a PKGBUILD before but I can't find anything definitely ruling it out.
 +
 
 +
Is it acceptable for a build function to start by removing directories in this way? Is it safe?
  
== /usr/sbin -> /usr/bin merge ==
+
--[[User:Margali|cfr]] ([[User talk:Margali|talk]]) 03:03, 27 February 2014 (UTC)
  
The Directories section needs to be updated to reflect the recent /bin, /sbin, /usr/sbin -> /usr/bin merge:
+
: I'd argue that this is an acceptable thing to do, at least in some cases. As an example, consider [http://www.talend.com/products/data-integration Talend Open Studio DI]: a single source file provides files for Windows, Linux, Mac OS, PowerPC (?) and Solaris. In response, the {{AUR|talend-open-studio-di}} PKGBUILD simply removes them. Does removing those files invite trouble? Yes. But removing files seems like an integral tool in the package maintainer's toolkit, and plenty of other weird stuff happens in PKGBUILDs too. [[User:Ichimonji10|Ichimonji10]] ([[User talk:Ichimonji10|talk]]) 02:20, 3 March 2014 (UTC)
* 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.
 
[[User:Kyrias|Kyrias]] ([[User talk:Kyrias|talk]]) 15:00, 6 June 2013 (UTC)
 
  
== Punctuation in PKGBUILD ==
+
== Unique sources ==
What is the official guidance regarding ending a pkgdesc in a period or using commas and English prose punctuation in general?
 
  
[[https://bbs.archlinux.org/viewtopic.php?pid=1288063 Link]] to discussion thread.
+
The source array should only contain unique sources names if a shares source directory is used. This applies to most github download. You can use "${pkgname}-${pkgver}.tar.gz::" prependet to each source to make the filename unique.
 +
I am not allowed to edit the page, could someone please do so?--[[User:NicoHood|NicoHood]] ([[User talk:NicoHood|talk]]) 15:33, 16 December 2016 (UTC)
  
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 15:17, 14 June 2013 (UTC)
+
== Add security standards ==
  
== There should be a clearly visible link to "Creating packages" page ==
+
As we decided to use https and GPG wherever possible for PKGBUILDs this should be added here as well. A Link to the mailing list would be also nice. The usage of strong hashes could also be mentioned, but I assume some people will not like the idea. A Link to the discussion about the hashes could also help for everyone to get his own opinion. It should be also mentioned that maintainers still need to validate the content of the downloads and test the update. Another important point is to contact upstream for GPG signatures if they are not available yet. One can link to some templates/tutorials I made on nicohood.de --[[User:NicoHood|NicoHood]] ([[User talk:NicoHood|talk]]) 19:40, 16 December 2016 (UTC)
  
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)
+
:Forget about the checksums part, as it was already declined multiple times by the developers. For the rest, patches welcome. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:19, 16 December 2016 (UTC)
 +
:edit: see also [[User:Apg#makepkg:_replace_default_checksums]] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:21, 14 March 2017 (UTC)

Latest revision as of 15:21, 14 March 2017

Fields order

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)

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)

Package naming

  • Package names should consist of alphanumeric characters only; all letters should be lowercase.
--unsigned
This is a guideline, but I see some packages with hypens and underscores (tesseract-data-chi_sim), dots (gstreamer0.10), plus (libxml++) and even at-signs (kde-l10n-ca@valencia). A package with uppercase name is libreoffice-bn-IN. According to the makepkg source, the allowed chars are: [:alnum:]+_.@-. Lekensteyn (talk) 22:38, 1 February 2014 (UTC)
"alphanumeric characters only" rule is ridiculous, 85% of official packages break this rule. I think it should be changed to allow hypens. It makes package names more readable. In regards to other characters, the + sign breaks AUR search (example, should be escaped). axper (talk) 11:19, 11 May 2014 (UTC)
  • 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.
--unsigned
  • 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.
--unsigned
This rule needs to get more stricter. Having a slash in the version breaks filenames. For craziness, I tried setting up a pkgver containing all characters from 0x01 to 0xff which makes makepkg throw a Bash syntax error. The current packages have versions matching {{ic}[[alnum:]._+~]+} (and a colon for epoch, a hypen for pkgrel). What about limiting to those characters? Debian has a similar set, see their policy docs Lekensteyn (talk) 22:38, 1 February 2014 (UTC)
  • 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.
--unsigned
  • Why is there no mentioning of suffixes for different build sources, such as vcs sources (-git, -hg, …) or binary distributions (-bin)? IMO this is an important part of the package naming conventions in AUR. Fordprefect (talk) 13:43, 10 May 2016 (UTC)

Is it acceptable for build() to start by removing directories?

I just downloaded a PKGBUILD whose build() function begins with the following:

find ./ -maxdepth 1 -mindepth 1 -type d  -exec rm -r {} \;

It seems to me that a PKGBUILD has no business doing this and that it is potentially dangerous. I admit that its danger will typically require people to do non-standard things and, arguably, things they would be better advised not to do anyway. But it still seems to me to invite trouble.

I don't remember seeing this in a PKGBUILD before but I can't find anything definitely ruling it out.

Is it acceptable for a build function to start by removing directories in this way? Is it safe?

--cfr (talk) 03:03, 27 February 2014 (UTC)

I'd argue that this is an acceptable thing to do, at least in some cases. As an example, consider Talend Open Studio DI: a single source file provides files for Windows, Linux, Mac OS, PowerPC (?) and Solaris. In response, the talend-open-studio-diAUR PKGBUILD simply removes them. Does removing those files invite trouble? Yes. But removing files seems like an integral tool in the package maintainer's toolkit, and plenty of other weird stuff happens in PKGBUILDs too. Ichimonji10 (talk) 02:20, 3 March 2014 (UTC)

Unique sources

The source array should only contain unique sources names if a shares source directory is used. This applies to most github download. You can use "${pkgname}-${pkgver}.tar.gz::" prependet to each source to make the filename unique. I am not allowed to edit the page, could someone please do so?--NicoHood (talk) 15:33, 16 December 2016 (UTC)

Add security standards

As we decided to use https and GPG wherever possible for PKGBUILDs this should be added here as well. A Link to the mailing list would be also nice. The usage of strong hashes could also be mentioned, but I assume some people will not like the idea. A Link to the discussion about the hashes could also help for everyone to get his own opinion. It should be also mentioned that maintainers still need to validate the content of the downloads and test the update. Another important point is to contact upstream for GPG signatures if they are not available yet. One can link to some templates/tutorials I made on nicohood.de --NicoHood (talk) 19:40, 16 December 2016 (UTC)

Forget about the checksums part, as it was already declined multiple times by the developers. For the rest, patches welcome. -- Alad (talk) 20:19, 16 December 2016 (UTC)
edit: see also User:Apg#makepkg:_replace_default_checksums -- Alad (talk) 15:21, 14 March 2017 (UTC)