Hi Zbyszek,

Based on the current dnf5 code for creating the "comps_group_package" table:

CREATE TABLE "comps_group_package" (
    "id" INTEGER,
    "group_id" INTEGER NOT NULL,
    "name_id" INTEGER NOT NULL,
    "installed" INTEGER NOT NULL,
    "pkg_type" INTEGER NOT NULL,
    FOREIGN KEY("group_id") REFERENCES "comps_group"("item_id"),
    FOREIGN KEY("name_id") REFERENCES "pkg_name"("id"),
    CONSTRAINT "comps_group_package_unique_name" UNIQUE ("group_id", "name_id"),
    PRIMARY KEY("id" AUTOINCREMENT)
);

It seems the only constraint is the uniqueness of the ('group_id', 'name_id'). In reviewing the SQL snippet from your report "(8134, (SELECT 'id' FROM 'pkg_name' WHERE 'name' = 'libavcodec-freeworld'), 0, 1)" where the state of the "libavcodec-freeworld" group package is stored in the DB with "installed = 0" (indicating it's an optional package), it suggests that either a package with such a name was already added for this group before, or the group was already present in the DB.

I cannot see how to achieve either of these states or reproduce it using the current dnf5 version. When a comps group is installed, it always receives a new id, even if it was installed before (e.g., 1. `dnf5 group install grp1`, 2. `dnf5 group install grp1 --with-optional` --> two different comps group ids being created in the DB). All packages defined in a given comps group are iterated and added to the "comps_group_package" table, and package names missing in the "pkg_name" table are created before that. The related code is here: https://github.com/rpm-software-management/dnf5/blob/5.1.12/libdnf5/transaction/db/comps_group.cpp#L130.

Based on this, it seems to me that the issue is due to some erroneous state, either a duplicate package name in the comps packages list or an existing group id in the "comps_group_package" table.

> either a duplicate package name in the comps packages list or an existing group id in the "comps_group_package" table.

I think the first option is unlikely, since more people would be hitting it.
I can provide diagnostic information, if you tell me what to look for.

Ran into this as well and I can reproduce it at the moment (with the current set of packages in the 41 development repos):

toolbox create -r 41 dnf5-test
toolbox run --container dnf5-test sudo dnf5 upgrade -y --refresh
toolbox run --container dnf5-test sudo dnf5 install -y @xfce-desktop-environment
toolbox run --container dnf5-test sudo dnf5 install -y https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-41.noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-41.noarch.rpm
toolbox run --container dnf5-test sudo dnf5 install -y @xfce-desktop-environment

Thanks for the great reproducer!
The issue occurs when a package is included in the comps.xml file multiple times. The issue here is with `multimedia` group:

```
<group>
    <id>multimedia</id>
    <name>Multimedia</name>
    <description>Audio/video framework common to desktops</description>
    <default>false</default>
    <uservisible>false</uservisible>
    <packagelist>
      <packagereq>gstreamer1-plugins-bad-freeworld</packagereq>
      <packagereq>gstreamer1-plugins-ugly</packagereq>
      <packagereq type="conditional" requires="chromium">libavcodec-freeworld</packagereq>
      <packagereq type="conditional" requires="firefox">libavcodec-freeworld</packagereq>
      <packagereq type="conditional" requires="libavcodec-free">libavcodec-freeworld</packagereq>
      <packagereq type="conditional" requires="libheif">libheif-freeworld</packagereq>
      <packagereq type="conditional" requires="pipewire">pipewire-codec-aptx</packagereq>
      <packagereq type="conditional" requires="qt5-qtwebengine">qt5-qtwebengine-freeworld</packagereq>
      <packagereq type="conditional" requires="vlc-libs">vlc-plugins-freeworld</packagereq>
    </packagelist>
  </group>
```

where `libavcodec-freeworld` is included as a conditional package three times with different requirements.

Thanks to your reproducer we should be able to fix it and write a test for this use-case.

Are you sure that medium is the correct priority for this bug?
The package management system is quite central to the system. If this is broken a lot of other tasks are blocked as well,
for example: Installing security updates - which is critical.

I would increase the priority and maybe add it to the F41 release blockers as well.
But - I'm also one of apparently few people affected by this bug. So my opinion might be biased. ;)

Sure, I've already begun working on the fix.

Feel free to propose the bug as F41 release blocker, but I'm not sure the bug is reproducible using only Fedora repositories. That doesn't mean the bug is not important to fix!

PR with the fix: https://github.com/rpm-software-management/dnf5/pull/1798
And here is the test: https://github.com/rpm-software-management/ci-dnf-stack/pull/1580

Proposed as a Blocker for 41-final by Fedora user mriss using the blocker tracking app because:

 Fedora is often used in combination with the rpmfusion repos. This bug is triggered by the rpmfusion repos and it stops the dnf5 package management. Package management is central to a distribution and not being able to install e.g. security updates is a major issue. I propose to include the fix for this bug before release.

Fedora 41 Final was declared GO today and we won't be evaluating blockers for the release anymore. Moving to Fedora 42 Final tracker.

I understand. Let's hope the fix can be pushed out soon to the regular updates repo.