On Tue, Feb 8, 2022 at 7:30 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> 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@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. > > 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@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
