On Fri, Feb 11, 2022 at 02:05:15PM +0100, Kevin Kofler via devel wrote: > Am Freitag, 11. Februar 2022 13:50:57 CET schrieb Jaroslav Mracek: > > On Tue, Feb 8, 2022 at 7:30 PM Zbigniew Jędrzejewski-Szmek < > > zbyszek@xxxxxxxxx> wrote: > > > 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. > > Yes, unmet reverse dependencies (Supplements) can only be found with > repository metadata. By definition, they will not show up in installed > package metadata, because they are reverse and unmet, so they are found in > the package that is not installed. > > I think that is the real issue that makes the langpack dependencies hard to > handle, not the fact that they are boolean (rich dependencies). Thank you both, I completely missed that part. This is indeed a problem. > The issue is that to know whether the dependency was *previously* unmet, > one would need the *previous* state of the repository metadata. But the > depsolving happens *after* refreshing the repository metadata, only the > local package metadata still reliably reflects the old state. So DNF would > have to back up the pre-sync metadata somewhere. > > So maybe the proper workaround for the langpack issue is not to handle > boolean dependencies specially, but to handle reverse dependencies > (Supplements) specially? Though I would still prefer seeing a solution that > always actually does what users expect without quirks, if at all possible. Right. So to handle previously-unmet Supplements nicely, we would need to know what Supplements were relevant and unmet (available in the whole package set, but unmet despite the supplemented package being installed locally). Wouldn't it be possible for dnf to just keep a flat list of such "unmet relevant Suggests" values? It seems that Suggests is used quite sparingly, so having a flat list of 1k-2k entries should not be a problem. E.g. at the end of each dnf transaction, just write down the whole list of "unmet relevant Suggests". > > 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. I think you are wrong here. We *can* adjust the guidelines, and we can quite feasibly adjust packages. Doing a provenpackager-fixup of the few dozens of wrongly-versioned packages can be easily done in a day. > That part needs to be rediscussed then. At least Miro and I were under the > (apparently false) impression that we had already reached agreement there, > because you did not object at the time. Ack. 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
