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. > 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. > 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? > I am sorry I can provide a long list of additional information to support > my statement but I hope it is not necessary. I also hope that it is not > necessary to share with you my experience in the development of DNF, > especially the part related to libsolv (DNF solver). I would be interested in knowing the exact technical difficulties, because logically, it should be possible. Kevin Kofler _______________________________________________ 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
