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
