From ArchWiki
Latest comment: 20 April by Aaron Liu in topic "Don't include base in depends" guideline?

Naming for install scripts.

In Special:Diff/635969 recommendations for naming install scripts were removed on the grounds that "the PKGBUILD format doesn't mandate it", but no one ever said it does; the previous wording was "should", not "must". Furthermore, it's downright necessary to give some name specific to the pkgname in the case of split packages, which the previous description handily accommodated.

Maybe this should read e.g.

The basename of the .install script should be the same as the pkgname in order to distinguish between split packages.

Thoughts? -- Eschwartz (talk) 02:40, 21 September 2020 (UTC)Reply[reply]

I don't see a reason to suggest a name at all. Is there a reason to standardize it?
Scimmia (talk) 02:48, 21 September 2020 (UTC)Reply[reply]
I don't get the split package use case. Each package_*() just specifies their own install file regardless of how it's named. -- nl6720 (talk) 14:36, 21 September 2020 (UTC)Reply[reply]

It looks like install script is no longer functional and has been replaced with ALPS?

-- Yiuin 10:58, 04 January 2020 (PST)

Not true at all. Hooks have taken over a lot of the boilerplate install scripts, moving the functionality to the package where it's actually needed, but that doesn't mean that install scripts aren't still used and fully functional for a wide variety of things.
Scimmia (talk) 19:04, 4 January 2021 (UTC)Reply[reply]
Oops, turns out I wasn't calling post_install from post_upgrade so it was skipping my post_install script. Sorry!
Yiuin (talk) 19:15, 4 January 2021 (UTC)Reply[reply]

(L)GPL version 3 only

The license section states that

(L)GPL has many versions and permutations of those versions. For (L)GPL software, the convention is:
    (L)GPL — (L)GPLv2 or any later version
    (L)GPL2 — (L)GPL2 only
    (L)GPL3 — (L)GPL3 or any later version

The last point about (L)GPL3 meaning "v3 or any later version" is in contradiction with /usr/share/licenses/common/LGPL3, which only includes version 3. There is no passage in v3 that says that v3 automatically means “v3 or any later version.”

So I suppose this is an error? Shouldn’t the abbreviation for “v3 or any later version” be “(L)GPL3+” or something similar?

--MJochim (talk) 12:06, 26 January 2022 (UTC)Reply[reply]

Deprecated topic: the text has changed because the licenses package now provides SPDX licenses and no longer provides /usr/share/licenses/common directory. -- RafaelFF (talk) 01:32, 23 January 2024 (UTC)Reply[reply]


If an .install script fails (without writing a message to stdout/stderr), one is not informed about this. There will still be [ALPM] transaction completed in the pacman logfile.

Maybe we can add to the "Tip" under the "install" section that pacman hooks have the option AbortOnFail. And shouldn't pacman hooks be preferred over .install scripts for that reason?

Langfingaz (talk) 15:53, 2 May 2022 (UTC)Reply[reply]

Sounds like a poorly written script.
Hooks are great for when multiple packages need to trigger it. install scripts are for things specific to that one package. Not really a case of preferring hooks over install scripts.
Scimmia (talk) 13:55, 3 May 2022 (UTC)Reply[reply]
Ok, I agree that there are different use cases for install scripts and hooks. But how about adding a note that it is the users responsibility to check for errors in an install script and print error messages?
If a poorly written hook fails without error messages one will at least see error: command failed to execute correctly by pacman.
Langfingaz (talk) 11:44, 29 May 2022 (UTC)Reply[reply]

Variable arch unclear

I am currently experimenting with the PKGBUILD of an AUR package that I'm contemplating to adopt. (The current maintainer is not very responsive.) The usage of arch=(...) looks suspicious. Unfortunately, the documentation doesn't help me at all. Especially:

arch=('x86_64') with one or more architectures indicates the package can be compiled for any of the specified architectures, but is architecture-specific once compiled. For these packages, specify all architectures that the PKGBUILD officially supports. For official repository and AUR packages, this means x86_64. Optionally, AUR packages may choose to additionally support other known working architectures.

IMHO this causes more confusion than clarification. This with one or more architectures doesn't match the initial arch=('x86_64'). What are the semantics of arch=(...) when the array contains more than one entry?

Many thanks in advance. Wolegis (talk) 18:59, 3 April 2023 (UTC)Reply[reply]

It's a bash array, just like every other bash array listed on this page. The semantics are no different. I dont think every section needs an explanation of the basics of bash.
The example listing one architecture does match the wording of one or more. What, exactly, is causing the confusion?
Scimmia (talk) 19:09, 3 April 2023 (UTC)Reply[reply]
Scimmia you completely missed the point. I know it's a bash array and I know pretty well what bash arrays can be used for. I try to rephrase: What's the point of specifying e.g. arch=('x86_64' 'i686')? Especially when the build function doesn't take into account arch, nor CARCH. Is the current value of arch (somehow magically) checked against the actual architecture used during build? Does it make any sense to overwrite arch in the package function? What will end up in the .PKGINFO of the resulting package? Wolegis (talk) 19:35, 3 April 2023 (UTC)Reply[reply]
As the page says, its a list of architectures you bac build the package for. Nothing magical about a simple bash script and a compiler building architecture specific binaries. As for overwriting it in the package function, whatever is the current value is what gets put on the package. If that specific package is different than the rest, there is no problem overwriting it.
Scimmia (talk) 19:53, 3 April 2023 (UTC)Reply[reply]
Is the current value of arch (somehow magically) checked against the actual architecture used during build?
Of course it does. Try to run makepkg on incompatible architecture and see.
$ makepkg
ERROR: package-name is not available for the 'x86_64' architecture.
Does it make any sense to overwrite arch in the package function?
Makepkg simply will not let you do that, you will get the error above.
Hanabishi (talk) 20:19, 3 April 2023 (UTC)Reply[reply]

Recommendations for using multiple licenses

I think we should add some guidelines in which cases it's recommended to use multiple licenses. Now it's unclear what do multiple licenses mean and when to use more than one license. See

—This unsigned comment is by Tocic (talk) 09:55, 7 May 2023. Please sign your posts with ~~~~!

It's bad design on the part of pacman, hence the motivation for proposing SPDX identifier support ( to clarify this situation. Right now specifying multiple licenses is meaningless, other than saying A and/or B may apply. Eclairevoyant (talk) 08:37, 15 July 2023 (UTC)Reply[reply]

Updating license section to reflect SPDX usage: a proposal

Review request

The section edited concerns official policies, so I believe the edit should be reviewed before being committed.

=== license ===

Warning: Arch Linux is currently undergoing a transition to SPDX style identifiers. Some issues may still require ironing out. This section focuses on the SPDX format. If you encounter any trouble, please report them and discuss with the community.

The license under which the software is distributed. Arch Linux uses SPDX license identifiers. Each license must have a corresponding entry in /usr/share/licenses/.

For common licenses (like 'GPL-3-or-later'), package licenses delivers all the corresponding files. The package is installed by default, as it is a dependency of base meta package, and the files may be found in /usr/share/licenses/common/. Simply refer to the license using its SPDX license identifier from the list of SPDX identifiers.

License families like BSD or MIT are, strictly speaking, not a single license and each instance requires a separate license file. In license variable refer to them using a common SPDX identifier (e.g. 'BSD-3-Clause' or 'MIT'), but then provide the corresponding file as if it was a custom license.

For custom licenses the identifier should be either LicenseRef-license-name or custom:license-name, if they are not covered by the common families mentioned above. The corresponding license text must be placed in directory /usr/share/licenses/pkgname. To install the file a following code snippet may be used in package() section:

install -Dm644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"

Combining multiple licenses or adding exceptions should follow the SPDX syntax. For example a package released under either GNU/GPL 2.0 or GNU/LGPL 2.1 could use 'GPL-2.0-or-later OR LGPL-2.1-or-later', while a package released under Apache 2.0 with LLVM exception: 'Apache-2.0 WITH LLVM-exception'. Note that this must be a single string, so the entire expression has to be enclosed in quotes. As for November 2023 SPDX list of exceptions is limited, so usually the custom licence route must be used.

If issues are encountered with SPDX identifiers, during the transitional period using old identifiers - names of the directories in /usr/share/licenses/common - is acceptable.

See also Nonfree applications package guidelines.

Additional information and perspectives on free and open source software licenses may be found on the following pages:

The end

Here the proposed change ends.

--Mpan (talk) 17:09, 4 November 2023 (UTC)Reply[reply]

Done. --Mpan (talk) 06:49, 15 November 2023 (UTC)Reply[reply]

No longer undergoing SPDX license change?

PKGBUILD#license mentions an undergoing transition to SPDX licenses. It seems to me the transition is done, considering that /usr/share/licenses/common/ is no more in the current licenses package in the official repositories (not just testing repositories). Are we still in SPDX transition or should the text be updated? -- RafaelFF (talk) 01:35, 23 January 2024 (UTC)Reply[reply]

I have a marker on March 1st to re-check, if that note is still needed.
As of January 23rd the transition is certainly still in progress. A large portion (if not majority) of official packages still use the old convention. I have no way to quickly check PKGBUILD sources (AUR, …), but I suspect the situation is even worse there.
The note is meant to warn the reader about the risk of things not yet working smoothly, including the format not being applicable to their case. So the message should stay in place until the convention becomes stable and well tested. --Mpan (talk) 11:11, 23 January 2024 (UTC)Reply[reply]
I had the impression the transition was solely the implementation in the licenses, not how the packages set the licenses field in PKGBUILD.
In this second case, then it makes sense to wait longer indeed. --RafaelFF (talk) 11:20, 23 January 2024 (UTC)Reply[reply]
So, it’s March.
Out of 13901 packages in [core] and [extra], 4894 have a valid SPDX license identifier, 8015 do not, and the remaining 992 haven’t been evaluated.
Based on a sample of 100 most recently updates entries in AUR: 69 valid, 31 not (all updated today). Another same-sized sample starting at 20000th entry (mid-Nov 2023): 27 valid, 73 not.
Given that adoption in official repos is 38%, I believe the note about a transitional period should stay in place and another evaluation should be conducted in 3 months. AUR went from 27% for November entries to 69% today, so I’m optimistic.
Among the most common offences are generic GPL and BSD names. Some instances look as if the author might’ve tried to use an SPDX identifier, but missed a dash or replaced “2.0” with “2”. Among ones I classified as valid is an oddity mixing “custom:” with a proper SPDX identifier: xdarkterror.lv2-gitAUR. Perhaps this gives a hint on how to update the section to make mistakes less likely.
--Mpan (talk) 23:20, 4 March 2024 (UTC)Reply[reply]

"Don't include base in depends" guideline?

I seem to recall there being a policy not to explicitly depend on `base` packages, since they're assumed to be installed on every system. OTOH, there are some clear counterexamples: on my system, for i in $(expac %D base); do printf '%s: ' "$i"; expac %N "$i" yields:

glibc: 399
gcc-libs: 164
bash: 85
systemd: 27
xz: 19
bzip2: 18
coreutils: 13
util-linux: 12
pacman: 10
gawk: 9
grep: 8
file: 7
sed: 6
pciutils: 5
findutils: 5
shadow: 4
procps-ng: 4
gzip: 4
gettext: 4
filesystem: 4
tar: 2
psmisc: 2
licenses: 2
iproute2: 2
archlinux-keyring: 2
systemd-sysvcompat: 1
iputils: 1

So which is it?

Gesh (talk) 12:48, 3 April 2024 (UTC)Reply[reply]

Even if there was such guideline, it would not be described on this page as it is not concerned with any guidelines. Arch package guidelines#Package dependencies says "List all direct library dependencies."
At the same time, users must have the base package installed as per Installation guide#Install essential packages, but that expectation is unrelated to how we handle package dependencies.
Lahwaacz (talk) 19:55, 3 April 2024 (UTC)Reply[reply]
> would not be described on this page as it is not concerned with any guidelines
That would seem to be the case, except we have a giant section, PKGBUILD#depends, that describes Arch policy. Aaron Liu (talk) 15:13, 20 April 2024 (UTC)Reply[reply]
I also noticed the shift in official packages [1]. They specify way more dependencies explicitly now.
But I can't find any info about it. I guess there are some internal rules.
Hanabishi (talk) 20:59, 3 April 2024 (UTC)Reply[reply]
I also recall this, but can't find it in the page history anywhere. All I can find is that transitive dependencies were switched to being included in 2020.
Personally I don't think any package needs to include glibc and gcc-libs. Aaron Liu (talk) 15:15, 20 April 2024 (UTC)Reply[reply]