RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2048394 - dnf should pull weak dependencies in install transaction
Summary: dnf should pull weak dependencies in install transaction
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: libdnf
Version: 9.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: swm-qe
Depends On:
Blocks: 2013327 2062812
TreeView+ depends on / blocked
Reported: 2022-01-31 06:43 UTC by Parag Nemade
Modified: 2022-05-17 16:22 UTC (History)
13 users (show)

Fixed In Version: libdnf-0.65.0-4.el9_0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2062812 (view as bug list)
Last Closed: 2022-05-17 15:55:20 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-110356 0 None None None 2022-01-31 06:53:54 UTC
Red Hat Product Errata RHBA-2022:3959 0 None None None 2022-05-17 15:55:33 UTC

Internal Links: 2033130

Description Parag Nemade 2022-01-31 06:43:25 UTC
Description of problem:
Its observed that dnf stopped installing weak dependencies post RHEL 9.0 Beta release composes. It was possible before to install any language support using command like "dnf install langpacks-hi" which installs all required langpacks on your system to give Hindi language experience to end user. This is now not possible in current nightly composes of RHEL-9.0

Langpacks has been developed to give end user a way to install language support. They are available since RHEL 7 and is the only way for end user to install any new language support post-install of RHEL system.

Version-Release number of selected component (if applicable):
[test@localhost ~]$ rpm -qa |grep dnf

How reproducible:

Steps to Reproduce:
1. Use any recent RHEL 9.0 nightly compose
2. try to install any available langpacks e.g. langpacks-fr or langpacks-it or langpacks-hi. Let's take langpacks-hi as an example here.
3. Observe that installation of those langpacks metapackages does not pull now libreoffice-langpack-hi, hunspell-hi and glibc-langpack-hi packages.

Actual results:
Installing langpacks packages are not installing all the satisfying weak dependencies.

Expected results:
Installing langpacks packages should install all the satisfying weak dependencies.

Additional info:
I think if langpacks-<lang> will not pull all the weakdeps then our gnome-software feature also got broken now. 
The gnome-software also provide langpacks installation. Just search langpacks in gnome-software.

We already have https://fedoraproject.org/wiki/Packaging:Langpacks guidelines approved to have end user install complete language support using weakdeps (langpacks metapackages) without manually installing each language support package.

Comment 1 Parag Nemade 2022-01-31 06:51:49 UTC
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
 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:    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:    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
 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 ~]$

Comment 2 Jaroslav Mracek 2022-02-01 08:56:31 UTC
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.

Comment 3 Jaroslav Mracek 2022-02-01 15:18:20 UTC
Do you agree to use workaround to resolve your issue?

Comment 4 Parag Nemade 2022-02-01 15:24:14 UTC

Comment 5 Jens Petersen 2022-02-04 09:30:08 UTC
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.

Comment 6 Miro Hrončok 2022-02-04 11:11:06 UTC
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

Comment 7 Miro Hrončok 2022-02-04 12:47:09 UTC
(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.

Comment 8 Jaroslav Mracek 2022-02-07 11:00:42 UTC
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?

Comment 9 Parag Nemade 2022-02-14 02:40:23 UTC
I will prefer old behaviour where langpacks work as it was working in RHEL9 Beta release.

Comment 13 Jaroslav Mracek 2022-02-21 13:33:21 UTC
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.

Comment 15 Parag Nemade 2022-02-21 13:39:03 UTC
I am not happy with whatever solutions are getting developed here. I only want to see this change reverted to 9-Beta.

Comment 16 Jaroslav Mracek 2022-02-23 08:18:31 UTC
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.

Comment 19 Parag Nemade 2022-03-02 06:18:04 UTC
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.

Comment 20 Samantha N. Bueno 2022-03-02 12:19:30 UTC
(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.

Comment 34 errata-xmlrpc 2022-05-17 15:55:20 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.