Bug 2048394

If you use RHEL 9.0 Beta then you will get result like this
[test@localhost ~]$ sudo dnf install langpacks-hi
Last metadata expiration check: 1:27:39 ago on सोमवार 31 जन॰ 2022 10:49:22 पूर्वाह्न.
Dependencies resolved.
===================================================================
 Package                 Arch   Version            Repo       Size
===================================================================
Installing:
 langpacks-hi            noarch 3.0-16.el9         AppStream  10 k
Installing dependencies:
 langpacks-core-font-hi  noarch 3.0-16.el9         AppStream  10 k
 langpacks-core-hi       noarch 3.0-16.el9         AppStream  10 k
 libreoffice-help-hi     x86_64 1:7.1.5.2-4.el9    AppStream 3.0 M
Installing weak dependencies:
 hunspell-hi             noarch 1:1.0.0-17.el9     AppStream  68 k
 hyphen-hi               noarch 1:0.7.0-19.el9     AppStream  14 k
 libreoffice-langpack-hi x86_64 1:7.1.5.2-4.el9    AppStream 395 k

Transaction Summary
===================================================================
Install  7 Packages

Total download size: 3.5 M
Installed size: 30 M
Is this ok [y/N]: n
Operation aborted.

But now using recent nightly composes, I see this behaviour got changed to
[test@rhel9 ~]$ sudo dnf install langpacks-hi
Last metadata expiration check: 1:13:19 ago on सोमवार 31 जन॰ 2022 11:05:46 पूर्वाह्न.
Dependencies resolved.
===================================================================
 Package                  Arch     Version       Repository   Size
===================================================================
Installing:
 langpacks-hi             noarch   3.0-16.el9    AppStream    11 k
Installing dependencies:
 langpacks-core-font-hi   noarch   3.0-16.el9    AppStream    11 k
 langpacks-core-hi        noarch   3.0-16.el9    AppStream    11 k

Transaction Summary
===================================================================
Install  3 Packages

Total download size: 32 k
Installed size: 1.1 k
Is this ok [y/N]: n
Operation aborted.
[test@rhel9 ~]$

The behavior is a consequence of following RFEs:
Bug 1699672 - RFE: dnf should not pull (already broken) weak dependencies on updates
Bug 2005305 - dnf should not pull (already unmet) weak dependencies on updates

Related bug:
Bug 2033130 - exclude_from_weak_autodetect=true effectively renders rich weak dependencies useless

I know that the mechanism is not perfect but the main problem is there are different expectation for the same feature. There are usercases where users wants to install weak deps and in other cases the don't. Also there are some technical limitation.

The mechanism cannot be applied differently for upgrade, downgrade, reinstall and install operation because DNF does all of them together and the rule can be only applyed to all operations. I also know that what is a beneficial for some one is an issue for another user.

In case that autodetection does not work, it can be switched off (from commandline --setopt=exclude_from_weak_autodetect=false on permanently in /etc/dnf/dnf.con) and maintained manually by user using `exclude_from_weak` configuration option.

In case of rich deps - there are multiple operators that makes any logic on top of it very difficult. To suggest whether they were met in past (conditions in rich deps) and not used.

Do you agree to use workaround to resolve your issue?

No

I would suggest that power-users can easily disable weak deps using this new setting,
but the default should be reverted IMO for the benefit of normal users.

This seems to be in all? ghc-*.spec files:

%package prof
Summary:        Haskell %{pkg_name} profiling library
Requires:       %{name}-devel%{?_isa} = %{version}-%{release}
Supplements:    (%{name}-devel and ghc-prof)


It is in https://docs.fedoraproject.org/en-US/packaging-guidelines/Haskell/#_spec_file_templates

(In reply to Miro Hrončok from comment #6)
> This seems to be in all? ghc-*.spec files:
> 
> %package prof
> Summary:        Haskell %{pkg_name} profiling library
> Requires:       %{name}-devel%{?_isa} = %{version}-%{release}
> Supplements:    (%{name}-devel and ghc-prof)
> 
> 
> It is in
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Haskell/
> #_spec_file_templates

I've apparently posted that to the wrong bugzilla.

Firs of all I need to clarify that the feature cannot be implemented only on upgrades - It cannot be achieved for two technical reason - 
1. DNF creates one transaction for all operations (install, upgrades are performed together).
2.a Install operation or commands (not only install) also triggers update. (example - I have already installed foo-1-1.noarch. Then I will install bar-2-2.noarch that requires foo-2. It means the install command will trigger upgrade that dnf cannot detect in advance. And if foo recommends something, it will be installed)
2.b Install operation with --best (default in RHEL) triggers always upgrade when package is already installed but in lower version.

Please could you provide your opinion for following options. I really afraid that we have not many other options (we are limited by a schedule and resources).

1. Keep it like it is
2. Disable autodetection
3. Start to ignore rich dependencies for autodetection of unmet weak dependencies. (may be we will be unable to deliver for GA)
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.

4. In theory the auto-detection can be only triggered by upgrade command but it will create an inconsistency in DNF behavior when upgrade operation is triggered by the another command (install, buildeps, downgrade, ...) - not preferable, see above (not for GA).

Which options are preferable?

I will prefer old behaviour where langpacks work as it was working in RHEL9 Beta release.

CI test: https://github.com/rpm-software-management/ci-dnf-stack/pull/1072

AC: DNF must not silence unmet weak dependencies that use rich dependencies on upgrade

The condition in rich deps is enough selecting. Additional auto-detection on top of it can negatively impact user expectations.

I am not happy with whatever solutions are getting developed here. I only want to see this change reverted to 9-Beta.

I am sorry I forgot to provide a link to the patch that resolves the issue: https://github.com/rpm-software-management/libdnf/pull/1439.

Can we have required acks set here soon along with DTM and ITM?
We request to fix this in RHEL 9.0.0 GA only.
We need to raise exception then.

(In reply to Parag Nemade from comment #19)
> Can we have required acks set here soon along with DTM and ITM?
> We request to fix this in RHEL 9.0.0 GA only.
> We need to raise exception then.

Hey Parag,
To get this into 9.0 at this point, an exception is required. Because you filed this issue, I would ask that you or Jens please set the exception? flag and fill out the corresponding justification.
Thanks,
Samantha

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: libdnf), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:3959