Bug 2091662 - Copr: Add support for other Fedora-based remixes
Summary: Copr: Add support for other Fedora-based remixes
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf-plugins-core
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Pavel Raiskup
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-05-30 16:37 UTC by Cappy Ishihara
Modified: 2023-04-21 01:23 UTC (History)
12 users (show)

Fixed In Version: dnf-plugins-core-4.4.0-1.fc36
Clone Of:
Environment:
Last Closed: 2023-04-21 01:23:53 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
A patch to check ID_LIKE for fedora (1.69 KB, patch)
2022-05-30 17:46 UTC, Cappy Ishihara
no flags Details | Diff
Added RHEL check (1.31 KB, patch)
2022-05-30 21:16 UTC, Cameron
no flags Details | Diff

Description Cappy Ishihara 2022-05-30 16:37:33 UTC
Description of problem:
Currently, the way that the Copr plugin guesses the chroot is to only check for the distro name in /etc/os-release. The plugin will check if the string "Fedora" or "Fedora Linux" is in the OS name and then return the chroot for Fedora, same for Mageia, OpenSUSE, and CentOS Stream. And if all else fails, the Copr plugin will assume EPEL.

This causes a small issue for Fedora-based distributions which tracks upstream Fedora (AKA Fedora Remixes) instead of RHEL (Ultramarine Linux, risiOS, and formerly Korora). In which Copr fails to assume the intended chroot.


Version-Release number of selected component (if applicable):
4.2.0-1.fc36

How reproducible:


Steps to Reproduce:
1. Install a Fedora Remix such as Ultramarine or risiOS
2. Attempt to enable a Copr project

Actual results:
The Copr plugin properly guesses the chroot right as Fedora.

Expected results:
Copr assumes the user wants the EPEL chroot.

Additional info:

Comment 1 Jaiden Riordan 2022-05-30 17:10:54 UTC
We are having the same issue in tauOS (RPM-OSTree). I think this could be solved with Yum variables, like calling for $fedorarelease or something similar. @cappy could you attempt setting a variable on your dnf-based distro? We previously had variables set for $releaseserver and $taurelease but it either broke when we switched to F36 or never worked.

Comment 2 Jaiden Riordan 2022-05-30 17:13:03 UTC
Additionally, maybe a fedora tag in systemd os-release would solve this.

Comment 3 Cappy Ishihara 2022-05-30 17:38:54 UTC
(In reply to Jaiden Riordan from comment #2)
> Additionally, maybe a fedora tag in systemd os-release would solve this.

In the case of Ultramarine and risiOS, we have an ID_LIKE variable in os-release. Doesn't really solve it.

(In reply to Jaiden Riordan from comment #1)
> We are having the same issue in tauOS (RPM-OSTree). I think this could be
> solved with Yum variables, like calling for $fedorarelease or something
> similar. @cappy could you attempt setting a variable on your
> dnf-based distro? We previously had variables set for $releaseserver and
> $taurelease but it either broke when we switched to F36 or never worked.

I checked out the code from dnf-plugins-core. It seems like they are checking in os-release to get the OS name and using the python3-distro module. 

Anyway, I tried setting the variable

➜  ~ DNF_VAR_fedorarelease=36 sudo dnf copr enable sukhmeet/mutter-rounded 
[sudo] password for cappy: 
Enabling a Copr repository. Please note that this repository is not part
of the main distribution, and quality may vary.

The Fedora Project does not exercise any power over the contents of
this repository beyond the rules outlined in the Copr FAQ at
<https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr>,
and packages are not held to any quality or security level.

Please do not file bug reports about these packages in Fedora
Bugzilla. In case of problems, contact the owner of this repository.

Do you really want to enable copr.fedorainfracloud.org/sukhmeet/mutter-rounded? [y/N]: y
Error: It wasn't possible to enable this project.
Repository 'epel-36-x86_64' does not exist in project 'sukhmeet/mutter-rounded'.
Available repositories: 'fedora-36-x86_64'

If you want to enable a non-default repository, use the following command:
  'dnf copr enable sukhmeet/mutter-rounded <repository>'
But note that the installed repo file will likely need a manual modification.

Comment 4 Cappy Ishihara 2022-05-30 17:46:20 UTC
Created attachment 1885234 [details]
A patch to check ID_LIKE for fedora

I have created a patch that may possibly fix this issue, by having it check ID_LIKE in os-release and checking for "fedora". But to not break compatibility with EPEL distros I have it check if "centos" or "rhel" is in the ID_LIKE first (AlmaLinux/Rocky does this)

One concern I have about this patch though is that IIRC RHEL actually only has "fedora" in their ID_LIKE. This may possibly break compatibility with RHEL itself, but not other distros.

Comment 5 Cameron 2022-05-30 20:16:42 UTC
Patch works on risiOS (and therefore should work on other downstream distros). I am currently installing RHEL's free version in a VM to test if it messes with RHEL.

Comment 6 Cameron 2022-05-30 21:16:17 UTC
Created attachment 1885312 [details]
Added RHEL check

Did not work on RHEL 9 first try, so I added a specific check for RHEL.

Comment 7 Jaiden Riordan 2022-06-01 02:03:30 UTC
(In reply to Cappy Ishihara from comment #3)
> (In reply to Jaiden Riordan from comment #2)
> > Additionally, maybe a fedora tag in systemd os-release would solve this.
> 
> In the case of Ultramarine and risiOS, we have an ID_LIKE variable in
> os-release. Doesn't really solve it.
I meant a new variable along the lines of FEDORA_VER.
> 
> (In reply to Jaiden Riordan from comment #1)
> > We are having the same issue in tauOS (RPM-OSTree). I think this could be
> > solved with Yum variables, like calling for $fedorarelease or something
> > similar. @cappy could you attempt setting a variable on your
> > dnf-based distro? We previously had variables set for $releaseserver and
> > $taurelease but it either broke when we switched to F36 or never worked.
> 
> I checked out the code from dnf-plugins-core. It seems like they are
> checking in os-release to get the OS name and using the python3-distro
> module. 
> 
> Anyway, I tried setting the variable
> 
> ➜  ~ DNF_VAR_fedorarelease=36 sudo dnf copr enable sukhmeet/mutter-rounded 
> [sudo] password for cappy: 
> Enabling a Copr repository. Please note that this repository is not part
> of the main distribution, and quality may vary.
> 
> The Fedora Project does not exercise any power over the contents of
> this repository beyond the rules outlined in the Copr FAQ at
> <https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-
> in-copr>,
> and packages are not held to any quality or security level.
> 
> Please do not file bug reports about these packages in Fedora
> Bugzilla. In case of problems, contact the owner of this repository.
> 
> Do you really want to enable
> copr.fedorainfracloud.org/sukhmeet/mutter-rounded? [y/N]: y
> Error: It wasn't possible to enable this project.
> Repository 'epel-36-x86_64' does not exist in project
> 'sukhmeet/mutter-rounded'.
> Available repositories: 'fedora-36-x86_64'
> 
> If you want to enable a non-default repository, use the following command:
>   'dnf copr enable sukhmeet/mutter-rounded <repository>'
> But note that the installed repo file will likely need a manual modification.
Maybe the releaseserver variable can remain tied to the Fedora version, but a separate remixversion variable can be added.

Thank you for the patches, our appreciation from the OSTree corner of the world.

Comment 8 Pavel Raiskup 2022-06-01 05:22:13 UTC
Would you mind opening a PR against https://github.com/rpm-software-management/dnf-plugins-core ?
That would make the patch review (and merge) easier.

Comment 9 Cappy Ishihara 2022-06-06 07:57:01 UTC
(In reply to Pavel Raiskup from comment #8)
> Would you mind opening a PR against
> https://github.com/rpm-software-management/dnf-plugins-core ?
> That would make the patch review (and merge) easier.

https://github.com/rpm-software-management/dnf-plugins-core/pull/458

Comment 10 Jan Kolarik 2023-04-05 09:10:26 UTC
Additionally discovered the resolving PR here: https://github.com/rpm-software-management/dnf-plugins-core/pull/463. Switching into POST.

Comment 11 Fedora Update System 2023-04-05 14:07:01 UTC
FEDORA-2023-c9d24d75a2 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c9d24d75a2

Comment 12 Fedora Update System 2023-04-06 02:24:55 UTC
FEDORA-2023-c9d24d75a2 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-c9d24d75a2`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-c9d24d75a2

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

Comment 13 Fedora Update System 2023-04-21 01:23:53 UTC
FEDORA-2023-c9d24d75a2 has been pushed to the Fedora 36 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.