[arch-dev-public] Library dependencies

[Xyne]

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