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
