It can be a little confusing for new users because the tooling will print warnings about this:
openiked W: Dependency glibc included but already satisfied openiked W: Dependency openssl included but already satisfied
But Arch's packaging policy says "Do not rely on transitive dependencies in any of the PKGBUILD#Dependencies, as they might break if one of the dependencies is updated."
These two things seem to be in conflict with each other, so I went with the policy statement as the deciding rule. Sure, but the issue is that 'glibc' is in the 'base' group that will exist on any Arch Linux install. There is a bit of debate whether we include these or not. Most people normally do not as it's a given on any system. In any case, 'glibc' is not really a transitive dependency in
On 25/08/2022 18:08, T.J. Townsend via aur-general wrote: that sense.
makedepends=('linux-headers' 'bison' 'cmake') 'bison' is in base-devel group so no need to include it here.
I can remove that, but it also sounds like a transitive dependency. Is base-devel an exception? Maybe the documentation on this issue could be clarified a bit. Again, this is specific to the build tools. 'makedepends' is meant for dependencies needed for building the package only and not at runtime. Therefore, when you are building the package you are guaranteed to have 'base-devel' group installed. So it's not needed and sometimes frowned upon to include these packages in makedepends.
The general idea behind all this is that these arrays should include only things that are not already guaranteed to exist for minimalism, tidiness, reducing confusion when someone reads your PKGBUILD, maintainability and so on. And you do kinda start to pick up on these with experience because once in a blue moon they do break your stuff and you remember it. :) -- Regards, Konstantin