On 04/12/2017 04:19 PM, Matthew Miller wrote:
On Wed, Apr 12, 2017 at 02:56:24PM +0200, Christian Dersch wrote:
On Wed, Apr 12, 2017 at 11:08:46AM +0200, Björn 'besser82' Esser wrote:
I hope someone can help me with the following question:
Does recent Fedora's rpm support nested rich-dependencies like:
Supplements: (pkg_a and pkg_b and pkg_c and (pkg_d or pkg_e))
Is there any way to express a dependency like that?
Can you give an example of when this might be a good idea? It seems
easy to go overboard with this without clear benefit.
The example is dnfdragora, a nice new GUI for DNF. It uses libyui
abstraction to provide native GUI/TUI for GTK+3, Qt and ncurses. The
rich-dependencies ensure that the right libyui bindings get
installed. So an Xfce user would get libyui-gtk while an LXQt user
would get libyui-qt.
So, in concrete terms:
Supplements: dnf and ____ and ____ and (libyui-gtk or libyui-qt)
?
What are the blanks? And the meaning is: this shouldn't show up as
a suggested addition unless those blanks _and_ a libyui of some sort
is already installed (or will be installed)?
Going back to the benefits question: why is this better than including
dnfdragora in the appropriate groups in comps?
Maybe I wrote not detailed enough or even a bit wrong, dnfdragora is the
use-case because it requires libyui and some toolkit binding. But that
stuff where we want to add that is libyui itself. So that the user gets
the libyui bindings matching his desktop environment. So libyui-qt would
supplement libyui and (plasma-desktop or lxqt-session) for example.
Similar with gtk. We want to ensure that the user always gets the
bindings for the toolkit his installed desktops use. So this is a logic
for libyui, not dnfdragora (which is just the application using it).
For comps: Yes, that is the right place for dnfdragora. It will end up
there with the change we proposed for Fedora 27:
https://fedoraproject.org/wiki/Changes/Replace_yumex-dnf_with_dnfdragora
Greetings,
Christian
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
