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
