On Tue, Feb 8, 2022 at 1:56 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> 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. > > > 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). > > > 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. > We will be happy to help you with the code improvement. Most of the logic is in libdnf (https://github.com/rpm-software-management/libdnf/) and libsolv (https://github.com/openSUSE/libsolv/). Even testing would be very helpful. Jaroslav > > Kevin Kofler > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
