Bug 17799 - urpmi does not support rpm's boolean dependencies
Summary: urpmi does not support rpm's boolean dependencies
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Low enhancement
Target Milestone: ---
Assignee: Thierry Vignaud
QA Contact:
URL:
Whiteboard:
Keywords:
: 17800 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-02-20 16:48 CET by Barry Jackson
Modified: 2023-07-12 13:42 CEST (History)
5 users (show)

See Also:
Source RPM: urpmi-8.101-1.mga6.noarch
CVE:
Status comment:


Attachments

Description Barry Jackson 2016-02-20 16:48:48 CET
Description of problem:
As per summary.
rpm-4.13 supports rich dependencies that allow for example, that a Recommend is only recommended if another package is already installed.

This works fine with raw rpm in cauldron, but is ignored by urpmi.

The reason for requesting this feature is that onboard now has a gnome shell extension which pulls in 160 packages when installed in a non-gnome system.

I would like to Recommend it, but doing so would burden KDE users with a great chunk of Gnome.

Recommends:    (%{name}-gnome-shell-extension if gnome-shell)

...would resolve this problem by only recommending the extension when gnome-shell is previously installed.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.


Reproducible: 

Steps to Reproduce:
Comment 1 Jani Välimaa 2016-02-20 18:22:31 CET
*** Bug 17800 has been marked as a duplicate of this bug. ***
Jani Välimaa 2016-02-20 18:25:56 CET

Assignee: bugsquad => thierry.vignaud

Comment 2 Thierry Vignaud 2016-02-23 13:53:34 CET
I know but that's depends on me completing the switch to libsolv in URPM.
As for now, such a package should be obviously recommended by a gnome package, so you don't really need it for now

Priority: Normal => Low
Severity: normal => enhancement

Comment 3 Barry Jackson 2016-03-04 13:19:30 CET
Onboard is a 'Gnome' package, but it's used by non Gnome users.

I really don't understand trying to associate particular packages to a particular desktop, as people just use whichever packages they prefer irrespective of desktop environment.
I use onboard in KDE and dolphin in MATE.
Comment 4 Nicolas Lécureuil 2016-06-06 14:01:27 CEST
Thierry do you think this switch can be done for mga7 ?

CC: (none) => mageia

Neal Gompa 2016-06-06 14:05:12 CEST

CC: (none) => ngompa13

Comment 5 Thierry Vignaud 2016-06-06 14:11:42 CEST
Maybe
Marja Van Waes 2017-12-02 12:00:23 CET

CC: (none) => mageiatools, marja11

Comment 6 Raphael Gertz 2023-07-10 00:29:54 CEST
Any hope for mga9 ?
Would it be possible to update the packaging guideline to clarify if this feature may or may not be used ?

CC: (none) => mageia

Comment 7 Nicolas Lécureuil 2023-07-10 09:54:49 CEST
Not done for mageia 9
Comment 8 Raphael Gertz 2023-07-11 05:06:48 CEST
May you confirm me that I respected the guidelines for haproxy ?

Should I use the rich dependencies instead of the good old virtual package ?

haproxy:
 requires virtual haproxy-server

haproxy-noquic:
 provides haproxy-server
 requires haproxy
 trigger pointing /usr/sbin/haproxy to /usr/sbin/haproxy-noquic

haproxy-quic:
 provides haproxy-server
 requires haproxy
 trigger pointing /usr/sbin/haproxy to /usr/sbin/haproxy-quic
Comment 9 Nicolas Lécureuil 2023-07-12 12:22:26 CEST
(In reply to Raphael Gertz from comment #8)
> May you confirm me that I respected the guidelines for haproxy ?
> 
> Should I use the rich dependencies instead of the good old virtual package ?

I just told you that urpmi does not support rich deps YET!
Comment 10 Raphael Gertz 2023-07-12 13:34:35 CEST
(In reply to Nicolas Lécureuil from comment #9)
> (In reply to Raphael Gertz from comment #8)
> > May you confirm me that I respected the guidelines for haproxy ?
> > 
> > Should I use the rich dependencies instead of the good old virtual package ?
> 
> I just told you that urpmi does not support rich deps YET!

This seems like a 6 year old fact and I suspect it's not a trivial feature to write which may takes time.

My only unanswered concern is how may we deal with specs files in the meantime:
- use rich dependencies ?
- wait for fix first ?
- or use virtual package workaround instead ?

Maybe my question is out of the scope of this bug report, if such sorry for the noise...
Comment 11 Nicolas Lécureuil 2023-07-12 13:42:48 CEST
rich deps are not allowed in urpmi and refused by the buildsystem.

I don't perl but i think this is not an easy task. I dreamed of this in mageia + but seems i have not dreamt enough :-)

Note You need to log in before you can comment on or make changes to this bug.