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.
> 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@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
_______________________________________________ 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
