Learn more about these different git repos.
Other Git URLs
Describe the issue
Comps groups for EPEL (notably EPEL 8 Next) seem to be processed in such a way that groups that declare dependencies on groups in the base OS have those dependencies filtered out. This leads to broken comps groups, and bugs like RH#1984706. Is it possible to stop that so things like the @kde-desktop-environment group isn't broken in the repo?
@kde-desktop-environment
When do you need this? (YYYY/MM/DD) As soon as possible.
When is this no longer needed or useful? (YYYY/MM/DD) I don't think that's ever actually going to happen.
If we cannot complete your request, what is the impact?
It becomes impossible to create comps groups that declare dependencies on base OS groups in EPEL, so people will have broken installs if they try to use them.
cc: @rdieter, @tdawson
Metadata Update from @mohanboddu: - Issue tagged with: medium-gain, medium-trouble, ops
Digging into this, it isn't just epel8-next. If we take the epel8 comps, strip out all the lang stuff, the change is pretty obvious. Note: This is ONLY on the <environment> section. No group or category sections are affected.
comps-epel8.xml.in
<environment> <id>kde-desktop-environment</id> <_name>KDE Plasma Workspaces</_name> <_description>The KDE Plasma Workspaces, a highly-configurable graphical user interface which includes a panel, desktop, system icons and desktop widgets, and many powerful KDE applications.</_description> <display_order>10</display_order> <grouplist> <groupid>base-x</groupid> <groupid>standard</groupid> <groupid>core</groupid> <groupid>admin-tools</groupid> <groupid>dial-up</groupid> <groupid>fonts</groupid> <groupid>input-methods</groupid> <groupid>multimedia</groupid> <groupid>networkmanager-submodules</groupid> <groupid>hardware-support</groupid> <groupid>printing</groupid> <groupid>guest-desktop-agents</groupid> <groupid>kde-desktop</groupid> </grouplist> <optionlist> <groupid>firefox</groupid> <groupid>kde-apps</groupid> <groupid>kde-education</groupid> <groupid>kde-media</groupid> <groupid>kde-office</groupid> </optionlist> </environment>
epel8 ...comps-Everything.x86_64.xml
<environment> <id>kde-desktop-environment</id> <name>KDE Plasma Workspaces</name> <description>The KDE Plasma Workspaces, a highly-configurable graphical user interface which includes a panel, desktop, system icons and desktop widgets, and many powerful KDE applications.</description> <display_order>10</display_order> <grouplist> <groupid>kde-desktop</groupid> </grouplist> <optionlist> <groupid>firefox</groupid> <groupid>kde-apps</groupid> <groupid>kde-education</groupid> <groupid>kde-media</groupid> <groupid>kde-office</groupid> </optionlist> </environment>
I have no idea why the <environment><grouplist> would be changed like that. I was a little worried that the wrong comps-xml.in file was being used. But when I check the epel8-next, I see the same thing, with missing groupid's, but the optionlist is the new list that I just changed last week.
<grouplist> <groupid>kde-desktop</groupid> </grouplist> <optionlist> <groupid default="true">firefox</groupid> <groupid default="true">kde-apps</groupid> <groupid>kde-education</groupid> <groupid default="true">kde-media</groupid> <groupid default="true">libreoffice</groupid> </optionlist> </environment>
So at this point, I have no idea what's going on when the comps files are made. Something stange.
If someone could point me in the right direction, maybe I could provide a patch. I've looked through all the releng scripts, configs, docs, and tests and can't find anything. Where are the scripts that make the epel repositories?
It would be in pungi... https://pagure.io/pungi/
I have a pull request to the epel8-next comps group that should fix the issue. https://pagure.io/fedora-comps/pull-request/678
Is it fixed now?
Nope I wonder if I need to actually put stuff in those groups. I'll try that.
I have a comps pull request that puts packages in the empty groups. https://pagure.io/fedora-comps/pull-request/687
The packages added are in those groups on RHEL8, so they should not add anything new that the user would not normally get when installing those groups.
I have merged it, lets wait and see what happens.
I have verified that our final solution works.
To clarify, the final solution is to have all the groups listed in the environment, in the same comps group, with at least one package in each of those groups. This allows the comps to have those comps groups listed in the environment. Then when they are listed, dnf knows how to handle different comps groups and processes them properly.
I believe this issue can be closed.
This should be documented so future EPEL releases have it too.
Metadata Update from @mohanboddu: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.