[arch-dev-public] Library dependencies
xyne at archlinux.org
Fri Dec 17 03:42:01 UTC 2021
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
>> 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
>> 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.
More information about the arch-dev-public