Re: Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM
On 02/20/2014 11:50 PM, Adam Williamson wrote: On Thu, 2014-02-20 at 14:44 +, Colin Walters wrote: On Thu, Feb 20, 2014 at 7:27 AM, Florian Festi ffe...@redhat.com wrote: We are currently working on adding weak and rich dependencies to upstream RPM. There are basically two parts: Is someone signed up to do the necessary frontend work for this on the dnf/yum side? If we're allowing choice of A | B like this, there needs to be a frontend that actually allows choosing, like aptitude. Fedora isn't signed up to *use* it yet. We can still make the choice whether we want to or not, I believe. 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 more interesting features are: No longer rely on other packages. With foo or bar you can choose between packages that do not have a common provide. With the reverse relations you can attach your package to another one without changing it. Being able to create 3rd party packages was one of the design goals of RPM and not being able to do such things from your own package breaks that. While this is not that important for the closed world view of a distribution it will become more important with COPR. Another important thing is being able to deal with more complicated situations. One kind are multilib problems like #442047 and #663269. I am pretty sure there are others, too. More interesting from a user perspective are bridging packages like language packs (see my previous mail) or optional plugins. Right now we need hand coded solutions like yum-langpack for something that should just be done by the packaging system. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM
(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 ands, 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM
Original Message Subject: [Rpm-maint] Heads up: Weak and rich dependencies in RPM Date: Thu, 20 Feb 2014 13:12:43 +0100 From: Florian Festi ffe...@redhat.com To: rpm-ma...@lists.rpm.org, rpm-l...@lists.rpm.org Hi! We are currently working on adding weak and rich dependencies to upstream RPM. There are basically two parts: #1 Adding weak dependencies as already used by SuSE and others: Recommends:, Suggests:, Supplements: and Enhances:. We agreed with Michael Schröder to not use SuSE's current implementation but to add new tags for a cleaner interface and an easy update path for already existing packages. This is planned to be part of the next RPM version. As old tools will just ignore the new tags this isn't a big compatibility issue. Support in rpmbuild can probably back ported easily. #2 Allow Boolean expressions of (Name Flag Version) terms in Requires:, Conflicts: and the new weak dependencies (rich dependencies). This will add a new expressive strength to RPM's dependency model and allow fixing a couple of packaging problems we don't have a solution for right now and also get rid of some special case solutions like hand coded language pack support. As we are still figuring out some of the implementation details and implications this feature may or may not make it in the next release. Packages using such Boolean expressions will not work with old versions of rpm and other related tools and it is still unclear to what extend this feature can be back ported. What implication does this have on your distribution? Stuff affecting other distributions left out Getting the support into createrepo and libsolv is taken care of. This should cover Fedora and OpenSUSE and may be others. I wrote a document describing more technical details. Find it attached to this mail. Florian rich_relations.odt Description: application/vnd.oasis.opendocument.text ___ Rpm-maint mailing list rpm-ma...@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM
On Thu, Feb 20, 2014 at 7:27 AM, Florian Festi ffe...@redhat.com wrote: We are currently working on adding weak and rich dependencies to upstream RPM. There are basically two parts: Is someone signed up to do the necessary frontend work for this on the dnf/yum side? If we're allowing choice of A | B like this, there needs to be a frontend that actually allows choosing, like aptitude. I guess one could go with the shortest package name wins approach or whatever the current heuristic is for now... This is also relevant with things like kickstart files, where there is no interactivity allowed. (For what it's worth I think making packaging even more complex and less predictable in order to increase flexibility is precisely the opposite direction of what we should be doing...but that's OK because I am coming at this from the other direction. We'll meet in the middle somehow ;) ) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM
On 02/20/2014 03:44 PM, Colin Walters wrote: On Thu, Feb 20, 2014 at 7:27 AM, Florian Festi ffe...@redhat.com wrote: We are currently working on adding weak and rich dependencies to upstream RPM. There are basically two parts: Is someone signed up to do the necessary frontend work for this on the dnf/yum side? If we're allowing choice of A | B like this, there needs to be a frontend that actually allows choosing, like aptitude. Yes and no. Right now there is no plan to allow the user to do the choosing. This ambiguity already exists in the current relations and we will continue to handle it automatically. I guess one could go with the shortest package name wins approach or whatever the current heuristic is for now... The heuristics will improved though. Libsolv already uses weak dependencies to choose the more desired package. I hope we can add support for preferring the more left packages over later packages in such or-clauses. That way Requires: sendmail or postfix would prefer sendmail while Requires: MTA chooses one of them the by some unrelated criteria. This is also relevant with things like kickstart files, where there is no interactivity allowed. (For what it's worth I think making packaging even more complex and less predictable in order to increase flexibility is precisely the opposite direction of what we should be doing...but that's OK because I am coming at this from the other direction. We'll meet in the middle somehow ;) ) Actually I am on your side of the argument. This effort is supposed to give better control over how packages behave and relate to each other *to the packager*. While A or B is an often demanded feature the main reason for this are relations that span a longer distance. E.g. Foo-langpack-es could Supplement: Foo and langsupport-es Or to implement the same behaviour with a forward dependency package Foo could Requires: Foo-langpack-es if langsupport-es Both variants pull in a intermediate package (Foo-langpack-es) if two packages are present (Foo and langsupport-es). Florian PS: I actually do think that we need to give the user more control over the packages, too. The current tools are completely inadequate to manage the number of packages we have in the distribution or even just on a system. But this is a story for another time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM
On Thu, 2014-02-20 at 14:44 +, Colin Walters wrote: On Thu, Feb 20, 2014 at 7:27 AM, Florian Festi ffe...@redhat.com wrote: We are currently working on adding weak and rich dependencies to upstream RPM. There are basically two parts: Is someone signed up to do the necessary frontend work for this on the dnf/yum side? If we're allowing choice of A | B like this, there needs to be a frontend that actually allows choosing, like aptitude. Fedora isn't signed up to *use* it yet. We can still make the choice whether we want to or not, I believe. I guess one could go with the shortest package name wins approach or whatever the current heuristic is for now... This is also relevant with things like kickstart files, where there is no interactivity allowed. Typical approach there is simply to come up with a 'default' approach, and that's what kickstarts use. If we use 'rich' dependencies, the questions would be to set policies for the use of each type of dependency in Fedora, and decide what level of 'weak' dependency to install by default. kickstart installs and live image creation would then, one expects, use that same level. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
