[arch-dev-public] Library dependencies
xyne at archlinux.org
Thu Dec 16 03:24:23 UTC 2021
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
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.
More information about the arch-dev-public