On Mon, Feb 7, 2022 at 5:20 PM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Miro Hrončok wrote:
> this is about the following Fedora change:
>
> https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect
>
> In the tracking bugzilla, the relevant comment is:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2013327#c4
>
> If I understand this correctly, the current implementation is not doing
> what the change described and the change owner says the feature cannot be
> implemented as described.
>
> There are several options and we should probably decide what to do before
> beta freeze. Hence opening this discussion.
>
> The change summarizes as "We would like to change a default behavior
> dnf/PackageKit/microdnf to install only newly recommended packages on
> upgrades." however the current impementation disbales weak depndencies in
> various other scenarios, as reported by various of our packagers e.g. in
>
> Bug 2048394 - dnf should pull weak dependencies in install transaction
> Bug 2033130 - exclude_from_weak_autodetect=true effectively renders rich
> weak dependencies useless
> Bug 2042808 - weakdeps not working on rawhide system
So, as I understand it, the core of the issue is this:
| We have a problem to detect rich dependencies correctly in autodetections
| because we do not know whether their conditions were met or not in past.
So basically, this leaves only 2 possible options (and the remainder are
variants thereof): either assume they were met or assume they were unmet:
> The change owner proposed 4 options to move forward. I understand them as
> follows:
>
> 1. do nothing, keep it broken
> 2. disable this behavior by default, keep it optional, but keep it broken
> 3. do not ignore already broken weak rich deps (partially reverts the
> change)
> 4. change the behavior on dynamically depending on the dnf command
> used (discouraged)
The status quo, i.e., 1., assumes they were met. Option 3. would assume they
were unmet.
Option 2. is like 1. but disables the entire feature by default.
Option 4. would attempt to heuristically, depending on the command used,
pick the behavior of 1. vs. either 2. or 3..
They are basically all workarounds for the real issue, which is that the
previous state cannot be correctly determined. Like Fabio Valentini, I have
to wonder why that cannot be done. DNF should have all the required
information in its database, or it could query RPM which also has the
information in its database.
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. 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. Rich dependencies are dynamic and they change from release to release (version macros, ...)
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).
Examples:
Requires: (pkgA or pkgB or pkgC)
Requires: (pkgA or (pkgB and pkgC))
Supplements: (foo and (lang-support-cz or lang-support-all))
Requires: ((pkgA with capB) or (pkgB without capA))
Supplements: ((driverA and driverA-tools) unless driverB)
Recommends: ((myPkg-langCZ and (font1-langCZ or font2-langCZ)) if langsupportCZ)
E.g., foo-langpack-xx Supplements: (foo and langpacks-xx) cannot possibly
have been already unmet if langpacks-xx was not previously installed. It
ought to be possible for DNF to determine that automatically.
So I would currently tend towards:
* postponing the Change to F37,
I prefer to keep it in Fedora 36 with solution 3 (rich dependencies in weak deps will be still fully functional like before the change). I already started with improvements: https://github.com/rpm-software-management/libdnf/pull/1439
DNF team is providing updates and improvements during the whole lifecycle of Fedora.
* implementing option 2. for F36 (i.e., adding the option as experimental
and disabled by default, which should not need a Change at all), AND
The option is or will be available in Fedora 35 but by defoult it is off (exclude_from_weak_autodetect). I do not thing there is a reason to change that.
* looking further for a proper solution for F37, as I do not believe it
cannot be done (and neither does Fabio).
Happy to hear that, but I do not know what I have to say.
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
