Hi,
On 17/12/2021 04:42, Xyne via arch-dev-public wrote:
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.
The example that comes to mind is docker[1]. This existed already (I
also think we had it in the repos) as a system tray tool / dock app[2].
The issue then was resolved by changing the tray app's name and binary
to docker-tray[3] and let the container tool docker have the docker name.
There have been discussions[4] about the name then. But in general we
can solve this kind of problems as was done then, by giving the
package/binary a suffix in the name.
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
[1] https://archlinux.org/packages/community/x86_64/docker/
[2] https://aur.archlinux.org/packages/docker-tray/
[3] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=docker-tray#n24
[4]
https://lists.archlinux.org/pipermail/aur-general/2013-November/026213.html
