Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1928181 - comps from the updates repo don't override comps from the fedora repo
Summary: comps from the updates repo don't override comps from the fedora repo
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 33
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: ---
Assignee: Daniel Mach
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-12 15:05 UTC by Kamil Páral
Modified: 2021-05-03 01:48 UTC (History)
15 users (show)

Fixed In Version: dnf-4.7.0-1.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-03 01:48:26 UTC
Type: Bug


Attachments (Terms of Use)
anaconda.log (13.76 KB, text/plain)
2021-02-12 15:06 UTC, Kamil Páral
no flags Details
dnf.librepo.log (5.08 KB, text/plain)
2021-02-12 15:06 UTC, Kamil Páral
no flags Details
packaging.log (14.87 KB, text/plain)
2021-02-12 15:06 UTC, Kamil Páral
no flags Details
program.log (1.70 KB, text/plain)
2021-02-12 15:06 UTC, Kamil Páral
no flags Details
syslog (480.66 KB, text/plain)
2021-02-12 15:06 UTC, Kamil Páral
no flags Details
dnf.cache (pruned large files) (661.13 KB, application/x-tar)
2021-02-12 15:07 UTC, Kamil Páral
no flags Details
Screenshot of the fixed software selection (160.90 KB, image/png)
2021-02-25 10:50 UTC, Vendula Poncova
no flags Details

Description Kamil Páral 2021-02-12 15:05:24 UTC
Description of problem:
In bug 1882358 we resolved a problem where certain "addon" package groups weren't marked for installation by default, when KDE was selected to be installed in netinst. In particular, we changed this in comps:

    <id>kde-desktop-environment</id>
    <name>KDE Plasma Workspaces</name>
    ...
    <optionlist>
      <groupid>3d-printing</groupid>
      <groupid>cloud-management</groupid>
      <groupid>firefox</groupid>
      <groupid>kde-apps</groupid>
      <groupid>kde-education</groupid>
      <groupid>kde-media</groupid>
      <groupid>kde-office</groupid>
      <groupid>kde-telepathy</groupid>
    </optionlist>

to this:

    <id>kde-desktop-environment</id>
    <name>KDE Plasma Workspaces</name>
    ...
    <optionlist>
      <groupid>3d-printing</groupid>
      <groupid>cloud-management</groupid>
      <groupid default="true">firefox</groupid>
      <groupid default="true">kde-apps</groupid>
      <groupid>kde-education</groupid>
      <groupid default="true">kde-media</groupid>
      <groupid default="true">kde-office</groupid>
      <groupid>kde-telepathy</groupid>
    </optionlist>

So 4 addons should be now selected by default. That really happens when I boot a F34 netinst. However, it doesn't happen when I boot F33 netinst. In F33 netinst, all addons are still unchecked by default.

I looked at /tmp/dnf.cache/ and I confirmed that both 'fedora' and 'updates' repos were downloaded, and that the 'updates' repo file contains <hash>-comps-Everything.x86_64.xml.gz which does include the correct changes as shown above.

I have a suspicion that even though both 'fedora' and 'updates' repos are downloaded, anaconda uses only the comps from the 'fedora' repo (or e.g. the first repo defined, or perhaps a random repo).

Below, I attach logs from my F33 netinst.

Version-Release number of selected component (if applicable):
anaconda 33.25.4-1.fc33
Fedora-Everything-netinst-x86_64-33-1.2.iso

How reproducible:
always, it seems

Steps to Reproduce:
1. boot F33 netinst
2. select KDE in Software Selection, see that no addons are checked by default
3. compare this to F34 netinst
4. confirm that the downloaded 'updates' repodata contain correct comps with default="true" next to certain KDE addons

Additional information:
If this is truly a bug, I understand this will no longer be fixed for F33. But I'd like to avoid the same situation in the future.

Comment 1 Kamil Páral 2021-02-12 15:06:08 UTC
Created attachment 1756633 [details]
anaconda.log

Comment 2 Kamil Páral 2021-02-12 15:06:12 UTC
Created attachment 1756634 [details]
dnf.librepo.log

Comment 3 Kamil Páral 2021-02-12 15:06:16 UTC
Created attachment 1756635 [details]
packaging.log

Comment 4 Kamil Páral 2021-02-12 15:06:20 UTC
Created attachment 1756636 [details]
program.log

Comment 5 Kamil Páral 2021-02-12 15:06:27 UTC
Created attachment 1756637 [details]
syslog

Comment 6 Kamil Páral 2021-02-12 15:07:30 UTC
Created attachment 1756638 [details]
dnf.cache (pruned large files)

Comment 7 Vendula Poncova 2021-02-16 11:03:58 UTC
I had some theories, but none of them seems to be related to this issue. I would guess that it depends on the priority of the repositories. Reassigning to DNF for further investigation.

Comment 8 Daniel Mach 2021-02-17 07:55:59 UTC
Comps merging depends on load order of the repositories.
It is the only option because the repo configuration has no other way to say what should come first.
There's the 'priority' option, but it is meant for packages and using it for comps would cause a lot of damage.

From the packaging log:
> 14:24:47,091 DBG packaging: repo updates: fall back enabled from default repos
> 14:24:47,091 DBG packaging: repo fedora: fall back enabled from default repos
That means load comps from 'updates' and override it with comps from 'fedora'.

Is Anaconda sorting or preserving order of the repos?
Does it load them in them in the order they were specified by the user?

Comment 9 Vendula Poncova 2021-02-17 10:21:19 UTC
These repositories are loaded from the configured directories with the DNF's read_all_repos method. I don't think that Anaconda changes their order after that. We only disable or enable them. Based on the implementation of the read_all_repos method, the .repo files are sorted by their path, so they are processed in the following order:

> find / -name *.repo | sort
/etc/anaconda.repos.d/fedora-cisco-openh264.repo
/etc/anaconda.repos.d/fedora-updates-testing.repo
/etc/anaconda.repos.d/fedora-updates.repo
/etc/anaconda.repos.d/fedora.repo

Comment 10 Daniel Mach 2021-02-23 12:25:55 UTC
Could you try the following dnf change?
https://github.com/rpm-software-management/dnf/pull/1734

Comment 11 Kamil Páral 2021-02-24 11:25:53 UTC
Vendula, if you can build an updates.img containing the change, I'll be happy to test it 🍰

Comment 12 Vendula Poncova 2021-02-25 10:48:43 UTC
(In reply to Daniel Mach from comment #10)
> Could you try the following dnf change?
> https://github.com/rpm-software-management/dnf/pull/1734

The fix seems to work fine. Here is the updates image: https://vponcova.fedorapeople.org/kde_updates.img

Comment 13 Vendula Poncova 2021-02-25 10:50:27 UTC
Created attachment 1759242 [details]
Screenshot of the fixed software selection

Comment 14 Kamil Páral 2021-02-25 11:30:31 UTC
Great, it works for me too. Dan, a thumbs up from me :-)

Comment 15 Fedora Update System 2021-04-19 16:13:02 UTC
FEDORA-2021-447fb19490 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-447fb19490

Comment 16 Fedora Update System 2021-04-19 18:33:48 UTC
FEDORA-2021-447fb19490 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-447fb19490`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-447fb19490

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 17 Fedora Update System 2021-05-03 01:48:26 UTC
FEDORA-2021-447fb19490 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


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