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. 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, * 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 * looking further for a proper solution for F37, as I do not believe it cannot be done (and neither does Fabio). 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
