From ArchWiki

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?

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


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)

unclear on depends

Dependencies defined inside the package() function are only required to run the software.

However, there is no package() function (I can't find it neither in the heading, nor by text search). Is this sentence obsolete, or could it please link to the correct place?

Ynikitenko (talk) 16:13, 29 June 2022 (UTC)

As it says, it's a function. See the very first statement on this page: This article discusses variables definable by the maintainer in a PKGBUILD. For information on the PKGBUILD functions and creating packages in general, refer to Creating packages. Also read PKGBUILD(5).
Scimmia (talk) 16:16, 29 June 2022 (UTC)
Yes, I read it and was just posting my answer, but the system broke. Anyway many thanks for the reply! In fact, now I think why is this page called PKGBUILD at all? Maybe this should be called "PKGBUILD variables"? Otherwise it's a bit misleading (I thought that was the complete reference). Ynikitenko (talk) 16:19, 29 June 2022 (UTC)
Anyway I think there would be no harm, if we add a link to the function, what do you think? Ynikitenko (talk) 16:24, 29 June 2022 (UTC)
In any case, I read both descriptions of the package() function, and they seem to provide no answer. In the man paragraph it states: "The package() function is used to install files into the directory that will become the root directory of the built package and is run after all the optional functions" - and there is no way to define package dependencies in that function (even if one declares a variable there, it will be local). So I'm afraid this sentence here is just wrong, and there is no other way to declare only runtime dependencies, is there?.. Ynikitenko (talk) 16:53, 29 June 2022 (UTC)
Might want to try it before making assumptions that everyone else is wrong. Scimmia (talk) 16:55, 29 June 2022 (UTC)
Sorry, I never wrote that everyone else is wrong. Your tone sounds aggressive as before, so I will be very thankful if you could just leave the discussion under my comments, thanks! Your comment does not add any valuable information to the point. Ynikitenko (talk) 17:07, 29 June 2022 (UTC)

So it is really unclear from the Wiki how to do that. However, I found an example from and and added that to the section. I very much hope that it won't get deleted as it usually happens on Arch Wiki! Ynikitenko (talk) 17:12, 29 June 2022 (UTC)

There's nothing unclear about declaring a variable. I undid your edit. If you really need to find an example on a forum for one of the simplest things in Bash, you might want to do some more reading first. Scimmia (talk) 17:13, 29 June 2022 (UTC)
If that is clear to you, it does not mean that it is clear to people who learn how Arch packaging works. Are these Wiki pages solely for those who are experts? As you can read from my comments, I really need to find an example on a forum for one of the simplest things in PKGBUILD. I think that if I need this in one particular place, then probably this place is not so well written as other parts of the article. Anyway I just have a feeling that you dislike me personally and immediately discourage any my actions in the Wiki (at least not on forums, thanks). Since when I wrote to maintainers of Arch Wiki and of Arch, no one even apologized to me (though you were a team member back then). To sum up, I am very unsure that your edit was to improve this page (for me it is the opposite). Anyway thanks for the comment here (though it, as usually, implies my incompetence - not sure it is necessary to be added that often though). Ynikitenko (talk) 17:38, 29 June 2022 (UTC)
Honestly, I didn't even recognize your name at all until you mentioned it just now. This has nothing to do with you personally, it's simply about your edits. The section in question even has examples already of how to declare variables, so it's already walking you through things step by step. Linking a forum post that just says the same things is pointless.
Scimmia (talk) 17:44, 29 June 2022 (UTC)

I agree that this article should not explain bash arrays. However, one could misinterpret the quote on top as: "At the end of the package() function there must only be the runtime-dependencies inside the depends array". Whereas the correct way is to add runtime-dependencies to that array during package().

Example: If you want A to be a build-and-runtime dependency and B a runtime-only dependency, then only the first of the following examples is correct. The second and third examples lead to A being only a build-dependency.

 depends=('A'); package(){ depends+=('B') }
 depends=('A'); package(){ depends=('B') }
 makedepends=('A'); package(){ depends=('B') }

--Langfingaz (talk) 21:12, 29 June 2022 (UTC)

Yes, it could be misinterpreted a thousand ways, but there is nothing we can do about it. — Lahwaacz (talk) 20:35, 30 June 2022 (UTC)