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).
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.
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.
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.
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
