Difference between revisions of "Talk:Arch packaging standards"

From ArchWiki
Jump to: navigation, search
m (Suggestions: more about .install files)
(PATCH Package naming: done, close)
 
(133 intermediate revisions by 33 users not shown)
Line 1: Line 1:
==Comments==
+
== Fields order ==
* What encoding (ascii ? UTF-8 ?) should be used for text files in submitted packages ? --[[User:Airbag|Airbag]] 13:43, 15 August 2006 (PDT)
 
  
==Suggestions==
+
[[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)
* 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)
 
* 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...?)==
+
== Punctuation in PKGBUILD ==
====Directories====
+
What is the official guidance regarding ending a pkgdesc in a period or using commas and English prose punctuation in general?
Is something like /usr/include/{pkg} allowed?
 
Is something like /usr/lib/{pkg}-{versionnumber} allowed? Same for /usr/share?
 
  
====Package Etiquette====
+
[[https://bbs.archlinux.org/viewtopic.php?pid=1288063 Link]] to discussion thread.
  
 +
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 15:17, 14 June 2013 (UTC)
  
...<br>
+
==Package naming==
file, or alternatively by exporting the PACKAGER environment variable before building packages with makepkg:
+
* Package names should consist of '''alphanumeric characters only'''; all letters should be '''lowercase'''.
<b>$</b> export PACKAGER="John Doe@<b>email</b>"
+
:--unsigned
  
====Architectures====
+
::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)
  
...<br>
+
:::"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)
depending on which architectures it can be built on. <s>You can also use</s> <b>State</b> 'any' for architecture independent packages.
 
  
...
+
* 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.
====Licenses====
+
:--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
  
*Add 'custom' to the licenses array. Optionally, <s>you can</s> replace 'custom' with 'custom:"name of license"'.
+
::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)
  
...<br>
+
* 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'''.
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 ...
+
:--unsigned
  
====Submitting Packages to the AUR====
+
* 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)
  
<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>
+
== Is it acceptable for build() to start by removing directories? ==
  
- I see no problem in repeating it here as regularly there are users not following that rule. [[User:Snowman|Snowman]]
+
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.
  
...<br>
+
I don't remember seeing this in a PKGBUILD before but I can't find anything definitely ruling it out.
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...
 
  
===Additional Guidelines===
+
Is it acceptable for a build function to start by removing directories in this way? Is it safe?
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===
+
--[[User:Margali|cfr]] ([[User talk:Margali|talk]]) 03:03, 27 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.
 
  
Examples of when to change the package release number:
+
: 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)
  
* Changing pkgdesc -> do NOT bump (unless it is severely wrong or something)
+
== Unique sources ==
* 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)
+
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)
  
===Adding system users===
+
== Add security standards ==
  
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.
+
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)
  
--[[User:OlivierMehani|OlivierMehani]] 19:31, 13 October 2011 (EDT)
+
: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)
  
See https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database
+
== Architecture Section not clear enough ==
  
I thinks it's a bit too specific to be listed here.
+
The arch array depends "on which architectures it can be built on". This is okay but I believe it should be clarified that the program also needs to run and work on that architecture. I know it's a bit "obvious" but people who write interpreted programs may understand that they should put "any" in the arch array even if their program is not usable at all for some architectures. [[User:Cecton|Cecton]] ([[User talk:Cecton|talk]]) 07:14, 28 April 2017 (UTC)
  
[[User:Snowman|Snowman]] 20:45, 13 October 2011 (EDT)
+
:How does fixing "built on" to "built for" prevent people from abusing {{ic|any}}? That's a separate problem. Also, interpreted programs like scripts ''should'' use {{ic|any}}, where do you think they shouldn't? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:39, 28 April 2017 (UTC)
 +
 
 +
::There is that program (debtap in AUR) wrote in bash that converts deb packages to Arch Linux packages. Unfortunately the program works only for i386 and amd64 because it fetches Ubuntu repositories at some specific locations. So when you run it on an arm architecture it fails with a curl output saying 404 which is not user friendly at all. IMHO a package should be restricted to the architectures where it works but in the specifications here, the only requirement is that it compiles. [[User:Cecton|Cecton]] ([[User talk:Cecton|talk]]) 09:08, 28 April 2017 (UTC)
 +
 
 +
:::Actually it is better specified here: [[PKGBUILD#arch]] "If instead a package can be compiled for any architecture, but is architecture-specific once compiled, specify all architectures officially supported by Arch, i.e. arch=('i686' 'x86_64'). " [[User:Cecton|Cecton]] ([[User talk:Cecton|talk]]) 10:10, 29 April 2017 (UTC)
 +
 
 +
== /opt vs /usr/share ==
 +
 
 +
Should there be a clause here or somewhere about preferring {{ic|/opt}} for big/self-contained AUR packages instead of {{ic|/usr/share}}? Isn't there such a policy? —'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<font color="gold">D</font><font color="orange">e</font><font color="red">t</font>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 17:17, 21 May 2017 (UTC)
 +
 
 +
:That's somewhat covered by the [http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html FHS]. There's no reason to make it specific only to AUR, even official packages like {{Pkg|cuda}} or {{Pkg|vtk6}} are installed into {{ic|/opt}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:34, 21 May 2017 (UTC)
 +
 
 +
::Do you mean that actual page? So sections like [[Arch packaging standards#Directories]] should really be replaced with a link there? —'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<font color="gold">D</font><font color="orange">e</font><font color="red">t</font>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 19:02, 21 May 2017 (UTC)
 +
 
 +
:::There you go, you even ''have'' the policy, so what's the point of this discussion really?? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:07, 21 May 2017 (UTC)
 +
 
 +
::::Alad, I'd appreciate it, if you didn't just come in and close an ongoing discussion. Anyway, so shouldn't that text be amended if that small piece is our official guideline? 1) Java is not installed in {{ic|/opt}} (neither {{Pkg|jre7-openjdk}} nor {{Pkg|jre8-openjdk}}), 2) what is a "self-contained" package? Can it have e.g. icons and desktop files in {{ic|/usr}}? I would hope so. —'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<font color="gold">D</font><font color="orange">e</font><font color="red">t</font>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 21:19, 21 May 2017 (UTC)
 +
 
 +
:::::Det, you really need to improve the way you ask questions. We don't have telepathic powers like you might have, so there is no way we could have guessed from the first post that you want an explanation for a section that you linked in your second post. Please read the standard reference on this topic, [http://www.catb.org/~esr/faqs/smart-questions.html How To Ask Questions The Smart Way].
 +
:::::Now back to the topic. You're right about Java, so I [https://wiki.archlinux.org/index.php?title=Arch_packaging_standards&diff=477997&oldid=462352 removed] that example. There are multiple reasons to use {{ic|/opt}}, most often it is because it may be too hard or even impossible to merge the software with the system's {{ic|/usr}} hierarchy. For example the software might come with bundled libraries which may conflict with the system libraries, this is where the "self-contained" comes from. If you take a look at the content of the {{pkg|cuda}} package, you will see that manual pages, licenses and desktop files are installed into {{ic|/usr/share}}.
 +
:::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:17, 22 May 2017 (UTC)
 +
 
 +
::::::Hmm. I don't think I was looking for an explanation to another article from the talk page of a different article. What "telepathic powers" that I "may have" have got to do with that, I've no clue. Also, I don't ''think'' I need patronisations about how to ask good questions. :-)
 +
::::::Anyway, as you can see from the flow of the conversation, first I thought there should be an AUR-specific instruction on {{ic|/opt}}. Then you say no, and there's also a different site. Then I ask about that other general one I found, different article, which is very cryptic, a bit out-of-date, and maybe that's the reason that it is. Then you respond, well exactly, that's what we already got, so why ask in the first place, and Alad closes the conversation?
 +
::::::Right? On the issue, I can see {{Pkg|cuda}} has its stuff elsewhere besides {{ic|/opt}}. ''However'', the ''point is'', why isn't it explained ''in that'' article? Why isn't ''your'' explanation in the article? Also, it currently says "large self-contained". What is the definition of ''large''? Smaller ones belong in {{ic|/usr}}?
 +
::::::''I'' don't need that explanation, the ''article'' needs it. People reading for the ''first time'' need it. Right? —'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<font color="gold">D</font><font color="orange">e</font><font color="red">t</font>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 08:24, 22 May 2017 (UTC)
 +
 
 +
==<s> Licenses: Don't mention prophetic new features that have nothing to do with packaging standards </s>==
 +
 
 +
The fifth bullet point talks about multiple licenses in a single package, and wisely points out that as an array, the {{ic|1=license=()}} metadata can and sometimes should contain multiple elements. Which is all fine and well... but then it goes on to speculate on a currently-nonexistent pacman feature. Quite frankly, the whole thing is a lie... this was added in the initial revision way back in 2005 and I don't think anyone even thinks of that as an interesting feature to have, let alone tried to implement it.
 +
 
 +
More importantly, it does not matter how pacman looks at the license metadata, or implements filtering on it. That has nothing to do with packaging standards (which is concerned with how to write a PKGBUILD). And having it there is confusing, especially when people read it and start wondering what that means they are supposed to put into their PKGBUILD. From the #archlinux IRC channel:
 +
 
 +
"What's the propper way to package a project that includes libs under a second license? The wiki says that listing multiple licenses works using OR instead of AND" and "Yes I know you can list licenses, but the wiki says pacman treats multiple licenses as essentially being a dual license, where the user can choose one, instead of being subject to both"
 +
 
 +
I strongly recommend deleting all but the first two sentences in that bullet point. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 23:18, 15 June 2017 (UTC)
 +
 
 +
:Thanks for reporting this, as you noted that section was unmaintained, so I've just [https://wiki.archlinux.org/index.php?title=Arch_packaging_standards&type=revision&diff=480743&oldid=477997 merged] it [https://wiki.archlinux.org/index.php?title=PKGBUILD&type=revision&diff=480744&oldid=480583 into] the corresponding section in the PKGBUILD article. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:44, 30 June 2017 (UTC)
 +
 
 +
:: Oh yes, this looks so much cleaner. <3 -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 15:35, 30 June 2017 (UTC)
 +
 
 +
==<s> Extend warning about custom variables to custom functions </s>==
 +
 
 +
Hi there!
 +
 
 +
I think that the warning to not introduce new variables into {{ic|PKGBUILD}}s should be extended to new functions as well.
 +
 
 +
I would replace the following wiki text under the paragraph "Package etiquette"
 +
 
 +
{{bc|<nowiki>* '''Do not introduce new variables''' into {{ic|PKGBUILD}} build scripts, unless the package cannot be built without doing so, as these could possibly '''conflict''' with variables used in makepkg itself.
 +
* If a new variable is absolutely required, '''prefix the variable name with an underscore''' ({{ic|_}}), e.g. {{bc|1=_customvariable=}}</nowiki>}}
 +
 
 +
with
 +
 
 +
{{bc|<nowiki>* '''Do not introduce new variables or functions''' into {{ic|PKGBUILD}} build scripts, unless the package cannot be built without doing so, as these could possibly '''conflict''' with variables and functions used in makepkg itself.
 +
* If a new variable or a new function is absolutely required, '''prefix its name with an underscore''' ({{ic|_}}), e.g. {{bc|1=_customvariable=}}</nowiki>}}
 +
 
 +
The result would be:
 +
 
 +
<blockquote>
 +
* '''Do not introduce new variables or functions''' into {{ic|PKGBUILD}} build scripts, unless the package cannot be built without doing so, as these could possibly '''conflict''' with variables and functions used in makepkg itself.
 +
* If a new variable or a new function is absolutely required, '''prefix its name with an underscore''' ({{ic|_}}), e.g. {{bc|1=_customvariable=}}
 +
</blockquote>
 +
 
 +
--[[User:Grufo|Grufo]] <sup>[ [[Special:Contributions/Grufo|contribs]] | [[User_talk:Grufo|talk]] ]</sup> 21:04, 23 July 2017 (UTC)
 +
 
 +
:Hi Grufo, your patch looks reasonable to me, I've just [https://wiki.archlinux.org/index.php?title=Arch_packaging_standards&type=revision&diff=482906&oldid=480743 applied] it, thank you :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:47, 24 July 2017 (UTC)
 +
 
 +
::@Kynikos Great! --[[User:Grufo|Grufo]] <sup>[ [[Special:Contributions/Grufo|contribs]] | [[User_talk:Grufo|talk]] ]</sup> 22:01, 24 July 2017 (UTC)
 +
 
 +
==<s> PATCH Package naming </s>==
 +
 
 +
I propose to change
 +
 
 +
{{bc|<nowiki>* Package names should consist of '''alphanumeric characters only'''; all letters should be '''lowercase'''.</nowiki>}}
 +
 
 +
into
 +
 
 +
{{bc|<nowiki>* Package names should '''only''' contain '''alphanumeric characters''' and any of <code>-+.</code>. All letters should be '''lowercase'''.</nowiki>}}
 +
 
 +
Result:
 +
 
 +
<blockquote>
 +
* Package names should '''only''' contain '''alphanumeric characters''' and any of '''<code>-+.</code>'''. All letters should be '''lowercase'''.
 +
</blockquote>
 +
 
 +
Even packages in the official repos use these characters.
 +
 
 +
[[User:Midgard|Midgard]] ([[User talk:Midgard|talk]]) 15:55, 12 August 2017 (UTC)
 +
 
 +
:Thank you, I've [https://wiki.archlinux.org/index.php?title=Arch_packaging_standards&action=historysubmit&type=revision&diff=485070&oldid=482906 applied] your patch, an example is {{Pkg|libxml++2.6-docs}} in ''extra''. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:54, 13 August 2017 (UTC)

Latest revision as of 02:54, 13 August 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)

Architecture Section not clear enough

The arch array depends "on which architectures it can be built on". This is okay but I believe it should be clarified that the program also needs to run and work on that architecture. I know it's a bit "obvious" but people who write interpreted programs may understand that they should put "any" in the arch array even if their program is not usable at all for some architectures. Cecton (talk) 07:14, 28 April 2017 (UTC)

How does fixing "built on" to "built for" prevent people from abusing any? That's a separate problem. Also, interpreted programs like scripts should use any, where do you think they shouldn't? -- Lahwaacz (talk) 08:39, 28 April 2017 (UTC)
There is that program (debtap in AUR) wrote in bash that converts deb packages to Arch Linux packages. Unfortunately the program works only for i386 and amd64 because it fetches Ubuntu repositories at some specific locations. So when you run it on an arm architecture it fails with a curl output saying 404 which is not user friendly at all. IMHO a package should be restricted to the architectures where it works but in the specifications here, the only requirement is that it compiles. Cecton (talk) 09:08, 28 April 2017 (UTC)
Actually it is better specified here: PKGBUILD#arch "If instead a package can be compiled for any architecture, but is architecture-specific once compiled, specify all architectures officially supported by Arch, i.e. arch=('i686' 'x86_64'). " Cecton (talk) 10:10, 29 April 2017 (UTC)

/opt vs /usr/share

Should there be a clause here or somewhere about preferring /opt for big/self-contained AUR packages instead of /usr/share? Isn't there such a policy? —Dettalk 17:17, 21 May 2017 (UTC)

That's somewhat covered by the FHS. There's no reason to make it specific only to AUR, even official packages like cuda or vtk6 are installed into /opt. -- Lahwaacz (talk) 18:34, 21 May 2017 (UTC)
Do you mean that actual page? So sections like Arch packaging standards#Directories should really be replaced with a link there? —Dettalk 19:02, 21 May 2017 (UTC)
There you go, you even have the policy, so what's the point of this discussion really?? -- Lahwaacz (talk) 20:07, 21 May 2017 (UTC)
Alad, I'd appreciate it, if you didn't just come in and close an ongoing discussion. Anyway, so shouldn't that text be amended if that small piece is our official guideline? 1) Java is not installed in /opt (neither jre7-openjdk nor jre8-openjdk), 2) what is a "self-contained" package? Can it have e.g. icons and desktop files in /usr? I would hope so. —Dettalk 21:19, 21 May 2017 (UTC)
Det, you really need to improve the way you ask questions. We don't have telepathic powers like you might have, so there is no way we could have guessed from the first post that you want an explanation for a section that you linked in your second post. Please read the standard reference on this topic, How To Ask Questions The Smart Way.
Now back to the topic. You're right about Java, so I removed that example. There are multiple reasons to use /opt, most often it is because it may be too hard or even impossible to merge the software with the system's /usr hierarchy. For example the software might come with bundled libraries which may conflict with the system libraries, this is where the "self-contained" comes from. If you take a look at the content of the cuda package, you will see that manual pages, licenses and desktop files are installed into /usr/share.
-- Lahwaacz (talk) 07:17, 22 May 2017 (UTC)
Hmm. I don't think I was looking for an explanation to another article from the talk page of a different article. What "telepathic powers" that I "may have" have got to do with that, I've no clue. Also, I don't think I need patronisations about how to ask good questions. :-)
Anyway, as you can see from the flow of the conversation, first I thought there should be an AUR-specific instruction on /opt. Then you say no, and there's also a different site. Then I ask about that other general one I found, different article, which is very cryptic, a bit out-of-date, and maybe that's the reason that it is. Then you respond, well exactly, that's what we already got, so why ask in the first place, and Alad closes the conversation?
Right? On the issue, I can see cuda has its stuff elsewhere besides /opt. However, the point is, why isn't it explained in that article? Why isn't your explanation in the article? Also, it currently says "large self-contained". What is the definition of large? Smaller ones belong in /usr?
I don't need that explanation, the article needs it. People reading for the first time need it. Right? —Dettalk 08:24, 22 May 2017 (UTC)

Licenses: Don't mention prophetic new features that have nothing to do with packaging standards

The fifth bullet point talks about multiple licenses in a single package, and wisely points out that as an array, the license=() metadata can and sometimes should contain multiple elements. Which is all fine and well... but then it goes on to speculate on a currently-nonexistent pacman feature. Quite frankly, the whole thing is a lie... this was added in the initial revision way back in 2005 and I don't think anyone even thinks of that as an interesting feature to have, let alone tried to implement it.

More importantly, it does not matter how pacman looks at the license metadata, or implements filtering on it. That has nothing to do with packaging standards (which is concerned with how to write a PKGBUILD). And having it there is confusing, especially when people read it and start wondering what that means they are supposed to put into their PKGBUILD. From the #archlinux IRC channel:

"What's the propper way to package a project that includes libs under a second license? The wiki says that listing multiple licenses works using OR instead of AND" and "Yes I know you can list licenses, but the wiki says pacman treats multiple licenses as essentially being a dual license, where the user can choose one, instead of being subject to both"

I strongly recommend deleting all but the first two sentences in that bullet point. -- Eschwartz (talk) 23:18, 15 June 2017 (UTC)

Thanks for reporting this, as you noted that section was unmaintained, so I've just merged it into the corresponding section in the PKGBUILD article. -- Kynikos (talk) 11:44, 30 June 2017 (UTC)
Oh yes, this looks so much cleaner. <3 -- Eschwartz (talk) 15:35, 30 June 2017 (UTC)

Extend warning about custom variables to custom functions

Hi there!

I think that the warning to not introduce new variables into PKGBUILDs should be extended to new functions as well.

I would replace the following wiki text under the paragraph "Package etiquette"

* '''Do not introduce new variables''' into {{ic|PKGBUILD}} build scripts, unless the package cannot be built without doing so, as these could possibly '''conflict''' with variables used in makepkg itself.
* If a new variable is absolutely required, '''prefix the variable name with an underscore''' ({{ic|_}}), e.g. {{bc|1=_customvariable=}}

with

* '''Do not introduce new variables or functions''' into {{ic|PKGBUILD}} build scripts, unless the package cannot be built without doing so, as these could possibly '''conflict''' with variables and functions used in makepkg itself.
* If a new variable or a new function is absolutely required, '''prefix its name with an underscore''' ({{ic|_}}), e.g. {{bc|1=_customvariable=}}

The result would be:

  • Do not introduce new variables or functions into PKGBUILD build scripts, unless the package cannot be built without doing so, as these could possibly conflict with variables and functions used in makepkg itself.
  • If a new variable or a new function is absolutely required, prefix its name with an underscore (_), e.g.
    _customvariable=

--Grufo [ contribs | talk ] 21:04, 23 July 2017 (UTC)

Hi Grufo, your patch looks reasonable to me, I've just applied it, thank you :) — Kynikos (talk) 16:47, 24 July 2017 (UTC)
@Kynikos Great! --Grufo [ contribs | talk ] 22:01, 24 July 2017 (UTC)

PATCH Package naming

I propose to change

* Package names should consist of '''alphanumeric characters only'''; all letters should be '''lowercase'''.

into

* Package names should '''only''' contain '''alphanumeric characters''' and any of <code>-+.</code>. All letters should be '''lowercase'''.

Result:

  • Package names should only contain alphanumeric characters and any of -+.. All letters should be lowercase.

Even packages in the official repos use these characters.

Midgard (talk) 15:55, 12 August 2017 (UTC)

Thank you, I've applied your patch, an example is libxml++2.6-docs in extra. -- Kynikos (talk) 02:54, 13 August 2017 (UTC)