On Tue, Feb 08, 2022 at 02:30:30PM +0100, Jaroslav Mracek wrote: > On Tue, Feb 8, 2022 at 1:56 PM Kevin Kofler via devel < > devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > Jaroslav Mracek wrote: > > > I am really sorry but this suggestion is incorrect. Basically we have 3 > > > major misunderstandings - what is rich deps and how it is evaluated, what > > > DNF stores in the history database and how SAT solver in libsolv works. > > > Rich deps are very complex things with multiple operators (and, or, if > > > unless, with, without) and can have multiple conditions. See examples > > > below from > > > > > https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html > > . > > > > They are arbitrarily complicated boolean expressions, but they are still > > always boolean expressions. They evaluate to either true or false > > depending > > on the contents of the RPM database. > > > > Not exactly, the second part is in metada of repository. The rest correct - > the evaluation is boolean, but complicated due to complex data (reldeps) > and in combination with version we have a lot of fun. See `(foo if (bas > 4 > with ham > 2))`. And we are still unable to do it correctly but solver can, > but only in transaction. Hmm, but why is metadata of repository needed? IIUC, all deps (including rich) are part of the package header, i.e. are in the RPM database for a package that is currently installed. E.g. 'rpm -qR …' shows rich deps. So, even if inefficient, we could just do a loop over 'rpm -qaR' and 'rpm -qaP' and resolve each and every Recommends to either true or false. > > > Also rich dependencies contain not names and versions of packages but > > > dependencies satisfied by provides. It is true that we have a history > > > database but it contains only the name of packagase but not what they > > > provided. > > > > Sorry, but this confuses me: What do you need the history for? I would > > expect the only thing that matters to be: Is the rich dependency > > *currently* > > met (true) or unmet (false)? "Currently" as in: at the time where the > > dependencies are computed, where no part of the transaction has actually > > run > > yet. That information is present at least in the RPM database. It ought to > > be present also in the databases DNF and/or libsolv use. > > > > I was only answering to previous reference that all information required > are in the DNF database. I understand that as history > > > Rich dependencies are dynamic and they change from release to release > > > (version macros, ...) > > > > That is a different issue, and also happens for non-rich dependencies. I > > think we agreed back when the Change was submitted that a dependency that > > changed in any way (such as a version bump) shall always be treated as a > > new > > dependency, did we not? > > > > No we didn't and it will make the feature less usable - see reported issues > during testing in original request ( > https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c74). Miro's reply was: "That was expected and we can make sure our packaging guidelines discourage Recommedns with full [NEVR]". Then there was follow-up discussion with general agreement that the example from #c74 was in fact a packaging mistake. In fact there was some discussion of amending the guidelines. So it seems that there is no need to treat versioned dependencies as special, i.e. a dep with with a changed version can be treated as a new dep. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
