[arch-dev-public] Library dependencies

[Allan McRae]

On 16/12/21 13:24, Xyne via arch-dev-public wrote:
> On 2021-12-15 16:40 +1000
> Allan McRae via arch-dev-public wrote:
>> 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?

Assuming that dependent library is not used elsewhere in the package, 
and the extra library had a provide of its library version, then this 
would add an extra dependency.

There are several options:
1) disable autodeps - these really do not need used everywhere...
2) split the package
3) move the binary into /usr/lib/<pkgname> and add a symlink to 
/usr/bin.  Then (assuming BIN_DIR=usr/bin is the usual search path), the 
dependency would not be added.

Saying that, I am against optional dependencies that are genuinely 
needed for a binary to run.  I think these should be used for features 
that could be dynamically loaded if the optional dependency is present. 
  I prefer package splitting if that is not the case.

>>> 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.

Do you have an example?  I don't like adding complexity for "what if" 
cases that may never occur.

For the case you described, cmd:foo is provided by two packages, foo1 
and foo2.  foo2 has a subset of the functionality.  Then you could 
depend on cmd:foo if either works, or foo1 if you need the full 
functionality.

>>> 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?
> 

 From memory, the space in "<pkgname>: <reason>" is important for 
optdepends.  I need to check, but I don't think the PKGBUILD linter will 
let PKGBUILDs with optdepends without the space build. And pacman will 
not split the string without it.  So this should be fine.

Allan