On Tue, Feb 8, 2022 at 7:30 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote:
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.
We need them to fulfill the workflow in DNF and for detection of unmet dependencies for Supplements. The process is as follows:
1. Iteration over all installed content and test recommends whether they are on the system or not. For Supplements: Iterate over all supplements of available packages and test them whether their supplemented package is installed.
2. Set the rule in the solver to not use packages that are supposed to be on the system but they are not as a candidate to satisfy weak dependencies
3. Run solver to create a transaction with required dependencies and weak dependencies.
> > > 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.
DNF is not a component only in Fedora and we have to support the LEGACY point of view. Changing guidelines is not an option because they are not mandatory but something as a recommendation. People will anyway ship packages with versioning of relation dependencies because they want, they can and they need them. Creating such a rule will only make things worse.
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
_______________________________________________ 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
