(I'm going to reply to the grandparent post here too, to avoid sending 2
separate mails.)
> On 02/20/2014 11:50 PM, Adam Williamson wrote:
>> Fedora isn't signed up to *use* it yet. We can still make the choice
>> whether we want to or not, I believe.
IMHO, we definitely want to use these features! There are so many situations
in which those features can be useful. One example: polkit should really:
Requires: not gnome-shell or polkit-gnome
Requires: not kde-workspace or polkit-kde
Requires: polkit-gnome or polkit-kde
(or if you prefer, one Requires with 2 "and"s, and the ordering can be
rearranged if it helps libsolv to do the right thing by default).
I even encountered a real-world example where boolean/conditional Obsoletes
would have helped:
These are the dracut* packages I have installed on Fedora 19:
dracut-norescue-029-2.fc19.x86_64
dracut-029-2.fc19.x86_64
(and also dracut-nohostonly, but that one is simply replaced by
dracut-generic, a simple package rename with Obsoletes that is not causing
any problems).
Now if I try to update to Fedora 20 using yum, this is what the depsolver
computes:
…
dracut x86_64 034-64.git20131205.fc20.1 updates 290 k
replacing dracut-norescue.x86_64 029-2.fc19
…
dracut-config-rescue x86_64 034-64.git20131205.fc20.1 updates 38 k
replacing dracut.x86_64 029-2.fc19
…
That is clearly not what I want! The problem here is that the default in the
main dracut package changed from rescue (with an optional -norescue
subpackage) to norescue (with an optional -config-rescue subpackage), and to
drag in dracut-config-rescue by default for people upgrading from the Fedora
19 default installation, the following was used in dracut-config-rescue:
Obsoletes: dracut <= 029
To handle this case properly, something like this would have been needed:
Obsoletes: dracut <= 029 and not dracut-norescue
or perhaps more appropriately:
Obsoletes: dracut <= 029 if not dracut-norescue
(The workaround in this case is to use "--exclude=dracut-config-rescue".)
Florian Festi wrote:
> Yup. And more important how to use them. While the two levels of
> weakness is the most obvious feature it is IMHO not the most important
> one. We are basically introducing the weaker level only for two reasons:
> That's what all other implementations do and it matches the structure of
> comps and thus may allow doing something group like in native rpm terms
> in the future.
>
> I have not yet seen an convincing use of those levels of weakness. If
> Fedora is willing to put some serious effort into this it might being
> used to have different package sets for the different Fedora.next
> products by setting different defaults. But whether that's feasible is
> still an open question IMHO.
The weakest-level Suggests: can be very useful for those GUI apps that wrap
a lot of packages, "require" them all for full functionality, but can be
used perfectly by many users without those packages. For example, in Ark
(the KDE archiving frontend), it would make sense to Recommends: the common
archivers and Suggests: the exotic ones.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
