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)

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)

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

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)

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

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)

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)

About Package Spliting

the post from bbs[2] told me that a split package is where one (set of) source material with one build process results in content that can be split logically into different packages. However, i didn't found anything about it in wiki. There should be similar words in wiki to avoid wrong use of package spliting. Should i add the sentence to somewhere or change some words? Sving1024 (talk) 15:51, 26 September 2024 (UTC)

This is already described in PKGBUILD#pkgbase. — Lahwaacz (talk) 07:04, 6 October 2024 (UTC)

# vim:set ts=2 sw=2 et:

Why is this exists in some PKGBUILD .

This should be config of each developer. oech3 (talk) 07:52, 18 April 2025 (UTC)

What does this have to do with this page? Scimmia (talk) 14:57, 22 April 2025 (UTC)

Linking to another page? oech3 (talk) 18:44, 22 April 2025 (UTC)

This is general text editor configuration, not something related to PKGBUILD... -- Alad (talk) 20:36, 22 April 2025 (UTC)

I'm fine if this talk is closed. I conside this should be not in PKGBUILD. Is it able to exclude the line without changing behavior of vi*? oech3 (talk) 09:03, 23 April 2025 (UTC)

I guess the point was the question if PKGBUILD files should contain this line and maybe which values should be used. But it is still out of scope since this page is not about guidelines, so I'm going to close this. — Lahwaacz (talk) 12:23, 26 April 2025 (UTC)

Note unrecommended hashsum functions

How about noting unrecommended hashsum functions? oech3 (talk) 09:04, 23 April 2025 (UTC)

This page is not about guidelines or recommendations. — Lahwaacz (talk) 12:24, 26 April 2025 (UTC)

OK. I'm fine to close this. oech3 (talk) 11:55, 27 April 2025 (UTC)