[arch-dev-public] Library dependencies

[Xyne]

On 2021-12-16 19:53 +1000
Allan McRae via arch-dev-public wrote:

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

I thought it was a supported use case but I agree with you that it's better to
split.


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

Nope, only a vague memory of some package conflict several years ago with two
identically named commands that did completely different things. I think it was
eventually solved by renaming one and telling upstream that the name was
already used for a common executable. So yeah, it's not really an issue.


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

Ok


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

I wasn't sure that the space was enforced. If it is, then there's no issue.



Coming back to your initial question:

>Any opinions on this would be greatly appreciated. Is this a better 
>system than the current one?  Is adding automatic dependencies against 
>the spirit of makepkg where everything is in the PKGBUILD?

It seems better to me. Less tedious and error-prone.

Regards,
Xyne