Dependencies with Subdepends (Bug #296)
Description
I encountered this with libgc:
Computing previously installed dependencies... libgc preparing environment... libgc checking dependencies... libgc has an optional dependency on gcc (c++ support) Do you want to use gcc? [y] y libgc requests gcc with CXX libgc has an optional dependency on gcc (gcj support) Do you want to use gcc? [y] n
So it defaults to wanting to rebuild gcc with gcj, because gcc is already installed.
Is there a better way to handle these kinds of dependencies? Probably through a configure line instead of using depends?
Or perhaps the depends logic should be updated to better handle automatic stuff regarding subdepends?
History
Updated by David Kowis over 1 year ago
Probably a duplicate of #295
Updated by Jaka Kranjc over 1 year ago
so what's the problem? That it prompts twice? Are the two subdependencies supposed to be enforced together or is each an option? If it is separate, is_depends_enabled+query+sub_depends and some logic would fix it.
Updated by Paul Vinogradov over 1 year ago
again, not the spell should be optional, but feature. sorcery doesn't recognize it. user can get gcc with gcj simultaneously. just because he didn't press 'n' in query.
Updated by Jaka Kranjc over 1 year ago
use manual spell logic as suggested then, it's the whole reason why sub_depends exists in the api.
Updated by David Kowis over 1 year ago
So the solution is manual spell logic, that's reasonable.
So this becomes then a bug in libgc that it's not doing the sub_depends logic correctly.