[arch-dev-public] Library dependencies

[Ike Devolder]

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