On 2021-12-15 16:40 +1000 Allan McRae via arch-dev-public wrote:
LIB_DIRS is specified in makepkg.conf, not in PKGBUILDs. Given usr/lib/ is not even standard for 64bit libraries, I do not want to hard code anything.
I somehow completely missed the part where you explicitly said it would be in makepkg.conf. That's exactly what I was suggesting precisely for the sake of having a centralized yet configurable setting. Sorry for the noise.
The dependencies added are purely sonames that the binary are explicitly linked to. So the binary will be non-function without libraries providing that exact soname. Thus all these dependencies are necessary.
Of course it will be up to the distribution to decide how much they use this feature - should all libraries provide their lib:soname value or just some? Dependencies are only added if there is a relevant provide.
What happens if a package includes "optional" binaries that depend on optdeps? Do those become hard deps?
As for extending this to other dependency types such as commands, I wonder if cmd:name would be specific enough. It's rare but sometimes unrelated commands can have the same name. Some sort of unique identifier may be required. I only mention it in case it should be considered for generalizing the syntax now before settling on a final format. Possibly something like "prefix:identifier/object", where "identifer/" is optional. So you would have "cmd:unique_cmd" for something unique but "cmd:foo/common_cmd" for some generic fungible common_cmd provided by different packages when a conflicting common_cmd exists in another package.
I don't see why we can not have multiple packages provide the same command. We already have multiple packages with the same provides entry, just with a package name and not a command name.
You can have multiple packages that provide the same command, but there may be rare cases where two conflicting packages provide unrelated commands with the same name, or a restricted version of a command that may not support the full argument set. It's worth considering how to handle such cases now before settling on a syntax.
How would this syntax work for optional deps btw? Also, if this is added, it would be useful to have an option to display the provider package of such deps in the output of pacman -Qi (e.g. -Qii).
For optdeps, what I mean is if the normal dependency would be "lib:libgpgme.so.11", how will you parse the normal optdep syntax of "pkgname: reason"? "lib:libfoo.so.13: required for the command foo". Won't using the same delimiter in two different contexts be problematic?
People can manually add such things as optional dependencies. I will need to look and see if pacman recognises provides as being installed (I think it does...).
I assumed that it did for dependency resolution. Regards, Xyne