Talk:PKGBUILD

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)

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)

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)

It looks like install script is no longer functional and has been replaced with ALPS? https://bbs.archlinux.org/viewtopic.php?id=224873

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

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)

(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)

install

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)

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)

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)

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)

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)

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)

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)

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.

arch=('i686')

$ 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)

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 https://bbs.archlinux.org/viewtopic.php?id=283734.

—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 (https://gitlab.archlinux.org/foxboron/licenses/-/issues/3) 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)

Updating license section to reflect SPDX usage: a proposal

=== 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:

• Wikipedia:Free software license
• Wikipedia:Comparison of free and open-source software licenses
• A Legal Issues Primer for Open Source and Free Software Projects
• GNU Project - Various Licenses and Comments about Them
• Debian - License information
• Open Source Initiative - Licenses by Name

--Mpan (talk) 17:09, 4 November 2023 (UTC)

Done. --Mpan (talk) 06:49, 15 November 2023 (UTC)