The epel-8-* and epel-9-* chroots in Fedora Copr are aliases to the "rhel+epel-*" chroots from `mock-core-configs` package. We'd like to have the same approach for `epel-10` once there's a released variant of RHEL 10 GA.
For now though, there's the variant `centos-stream+epel-10` in the new mock-core-configs release, though:
https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1
So we could make `epel-10-*` an alias to `centos-stream+epel-10` for the time being, and do the switch to `rhel+epel-10` later on. Do you think this makes sense? Or is it just too early?
Pavel
On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup praiskup@redhat.com wrote:
The epel-8-* and epel-9-* chroots in Fedora Copr are aliases to the "rhel+epel-*" chroots from `mock-core-configs` package. We'd like to have the same approach for `epel-10` once there's a released variant of RHEL 10 GA.
For now though, there's the variant `centos-stream+epel-10` in the new mock-core-configs release, though:
https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1So we could make `epel-10-*` an alias to `centos-stream+epel-10` for the time being, and do the switch to `rhel+epel-10` later on. Do you think this makes sense? Or is it just too early?
For EPEL 10, we would never do that switch. CentOS Stream + EPEL is the default case for EPEL 10 now. RHEL + EPEL configs are the alternative.
So we would just have the alias and keep it "forever".
-- 真実はいつも一つ！/ Always, there's only one truth!
Neal Gompa venit, vidit, dixit 2024-08-15 16:14:30:
On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup praiskup@redhat.com wrote:
The epel-8-* and epel-9-* chroots in Fedora Copr are aliases to the "rhel+epel-*" chroots from `mock-core-configs` package. We'd like to have the same approach for `epel-10` once there's a released variant of RHEL 10 GA.
For now though, there's the variant `centos-stream+epel-10` in the new mock-core-configs release, though:
https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1So we could make `epel-10-*` an alias to `centos-stream+epel-10` for the time being, and do the switch to `rhel+epel-10` later on. Do you think this makes sense? Or is it just too early?
For EPEL 10, we would never do that switch. CentOS Stream + EPEL is the default case for EPEL 10 now. RHEL + EPEL configs are the alternative.
So we would just have the alias and keep it "forever".
I think we're mixing "mock core config name" and "copr chroot name" in this dicussion.
epel-7-x86_64.cfg is the latest epel-* mock config I see in /etc/mock. Everything else is explicit (centos-stream+epel, rhel+epel, ...).
The copr chroots epel-* etc always made me look twice what they actually are. Even switching the meaning "in between" makes it only.
And I really think epel-* makes no sense since it's always "+" to something. EPEL guidelines spell out what is the official base distro for which EPEL (next or what not). That is something we could add next to the respective chroot in copr (just like the current remarks there).
Cheers Michael
On čtvrtek 15. srpna 2024 17:02:30, SELČ Michael J Gruber wrote:
Neal Gompa venit, vidit, dixit 2024-08-15 16:14:30:
On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup praiskup@redhat.com wrote:
The epel-8-* and epel-9-* chroots in Fedora Copr are aliases to the "rhel+epel-*" chroots from `mock-core-configs` package. We'd like to have the same approach for `epel-10` once there's a released variant of RHEL 10 GA.
For now though, there's the variant `centos-stream+epel-10` in the new mock-core-configs release, though:
https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1So we could make `epel-10-*` an alias to `centos-stream+epel-10` for the time being, and do the switch to `rhel+epel-10` later on. Do you think this makes sense? Or is it just too early?
For EPEL 10, we would never do that switch. CentOS Stream + EPEL is the default case for EPEL 10 now. RHEL + EPEL configs are the alternative.
Don't you have a documentation link for this?
So we would just have the alias and keep it "forever".
I think we're mixing "mock core config name" and "copr chroot name" in this dicussion.
One of the things Copr tries to do is to use mock-core-configs as-is (unchanged); while the previous epel-N chroots were tricky, the change Neal mentioned seems to fix this!
epel-7-x86_64.cfg is the latest epel-* mock config I see in /etc/mock. Everything else is explicit (centos-stream+epel, rhel+epel, ...).
The copr chroots epel-* etc always made me look twice what they actually are. Even switching the meaning "in between" makes it only.
Indeed, this is tricky. Another best effort Fedora Copr goal was to be as close to Fedora Koji as possible. So if Koji builds particular EPEL-N against {RHEL,CentOS,CentOS Stream}+EPEL, Fedora Copr (and mock-core-configs, too) wants to do the same thing (even though by default an official released set of packages is used instead of pre-release official buildroot).
And I really think epel-* makes no sense since it's always "+" to something. EPEL guidelines spell out what is the official base distro for which EPEL (next or what not). That is something we could add next to the respective chroot in copr (just like the current remarks there).
The 'epel-10' chroot in Copr and mock-core-configs makes sense for user's convenience, and I believe we want to have it. That's NB also the default "dnf copr enable" choice on Enterprise Linux machines.
Can you give me the corresponding link to the EPEL guidelines?
Pavel
Cheers Michael
Pavel Raiskup venit, vidit, dixit 2024-08-16 11:06:21:
On čtvrtek 15. srpna 2024 17:02:30, SELČ Michael J Gruber wrote:
Neal Gompa venit, vidit, dixit 2024-08-15 16:14:30:
On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup praiskup@redhat.com wrote:
The epel-8-* and epel-9-* chroots in Fedora Copr are aliases to the "rhel+epel-*" chroots from `mock-core-configs` package. We'd like to have the same approach for `epel-10` once there's a released variant of RHEL 10 GA.
For now though, there's the variant `centos-stream+epel-10` in the new mock-core-configs release, though:
https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1So we could make `epel-10-*` an alias to `centos-stream+epel-10` for the time being, and do the switch to `rhel+epel-10` later on. Do you think this makes sense? Or is it just too early?
For EPEL 10, we would never do that switch. CentOS Stream + EPEL is the default case for EPEL 10 now. RHEL + EPEL configs are the alternative.
Don't you have a documentation link for this?
So we would just have the alias and keep it "forever".
I think we're mixing "mock core config name" and "copr chroot name" in this dicussion.
One of the things Copr tries to do is to use mock-core-configs as-is (unchanged); while the previous epel-N chroots were tricky, the change Neal mentioned seems to fix this!
We're on the same board here!
epel-7-x86_64.cfg is the latest epel-* mock config I see in /etc/mock. Everything else is explicit (centos-stream+epel, rhel+epel, ...).
The copr chroots epel-* etc always made me look twice what they actually are. Even switching the meaning "in between" makes it only.
Indeed, this is tricky. Another best effort Fedora Copr goal was to be as close to Fedora Koji as possible. So if Koji builds particular EPEL-N against {RHEL,CentOS,CentOS Stream}+EPEL, Fedora Copr (and mock-core-configs, too) wants to do the same thing (even though by default an official released set of packages is used instead of pre-release official buildroot).
Yep!
And I really think epel-* makes no sense since it's always "+" to something. EPEL guidelines spell out what is the official base distro for which EPEL (next or what not). That is something we could add next to the respective chroot in copr (just like the current remarks there).
The 'epel-10' chroot in Copr and mock-core-configs makes sense for user's convenience, and I believe we want to have it. That's NB also the default "dnf copr enable" choice on Enterprise Linux machines.
In mock-core-configs probably, because users don't have to look up which config is "for epel-9", e.g., or which release is "rawhide".
But there's a difference betwen mock and copr here: - If I built in mock f41 (last week) which is a link to rawhide I in fact used the rawhide buildroot etc, not a copy of it. (disttag f41, and methinks rawhide should link to f41, not vice versa, but that's a different issue)
- If I build in mock against chroots for linked mock configs I have separate buildroots and builds.
I don't think we want the latter, but I may be wrong.
Can you give me the corresponding link to the EPEL guidelines?
I'm not sure whether the target base info is technically part of the policy in the policy page, but that's what I was thinking of:
https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy
Cheers Michael
Hello Michael,
On pátek 16. srpna 2024 11:31:15, SELČ Michael J Gruber wrote:
Pavel Raiskup venit, vidit, dixit 2024-08-16 11:06:21:
On čtvrtek 15. srpna 2024 17:02:30, SELČ Michael J Gruber wrote:
Neal Gompa venit, vidit, dixit 2024-08-15 16:14:30:
On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup praiskup@redhat.com wrote:
The epel-8-* and epel-9-* chroots in Fedora Copr are aliases to the "rhel+epel-*" chroots from `mock-core-configs` package. We'd like to have the same approach for `epel-10` once there's a released variant of RHEL 10 GA.
For now though, there's the variant `centos-stream+epel-10` in the new mock-core-configs release, though:
https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1So we could make `epel-10-*` an alias to `centos-stream+epel-10` for the time being, and do the switch to `rhel+epel-10` later on. Do you think this makes sense? Or is it just too early?
For EPEL 10, we would never do that switch. CentOS Stream + EPEL is the default case for EPEL 10 now. RHEL + EPEL configs are the alternative.
Don't you have a documentation link for this?
So we would just have the alias and keep it "forever".
I think we're mixing "mock core config name" and "copr chroot name" in this dicussion.
One of the things Copr tries to do is to use mock-core-configs as-is (unchanged); while the previous epel-N chroots were tricky, the change Neal mentioned seems to fix this!
We're on the same board here!
epel-7-x86_64.cfg is the latest epel-* mock config I see in /etc/mock. Everything else is explicit (centos-stream+epel, rhel+epel, ...).
The copr chroots epel-* etc always made me look twice what they actually are. Even switching the meaning "in between" makes it only.
Indeed, this is tricky. Another best effort Fedora Copr goal was to be as close to Fedora Koji as possible. So if Koji builds particular EPEL-N against {RHEL,CentOS,CentOS Stream}+EPEL, Fedora Copr (and mock-core-configs, too) wants to do the same thing (even though by default an official released set of packages is used instead of pre-release official buildroot).
Yep!
And I really think epel-* makes no sense since it's always "+" to something. EPEL guidelines spell out what is the official base distro for which EPEL (next or what not). That is something we could add next to the respective chroot in copr (just like the current remarks there).
The 'epel-10' chroot in Copr and mock-core-configs makes sense for user's convenience, and I believe we want to have it. That's NB also the default "dnf copr enable" choice on Enterprise Linux machines.
In mock-core-configs probably, because users don't have to look up which config is "for epel-9", e.g., or which release is "rawhide".
But there's a difference betwen mock and copr here:
- If I built in mock f41 (last week) which is a link to rawhide I in fact used the rawhide buildroot etc, not a copy of it. (disttag f41, and methinks rawhide should link to f41, not vice versa, but that's a different issue)
There was no f41 chroot in Copr until now (enabled them ~5 minutes ago, you reminded me to do so, thanks!).
In a local mock build, yes. The latest `mock-core-configs` update https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1 did the change.
- If I build in mock against chroots for linked mock configs I have separate buildroots and builds.
I don't think we want the latter, but I may be wrong.
We do not enable the symlinked chroots in Copr, actually. So this should be fine? I'm not sure I 100% understand your concern, so please elaborate.
Can you give me the corresponding link to the EPEL guidelines?
I'm not sure whether the target base info is technically part of the policy in the policy page, but that's what I was thinking of:
https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy
Thanks. It should document EPEL 10, too. Requested here: https://pagure.io/epel/issue/290
Pavel
Cheers Michael
Pavel Raiskup venit, vidit, dixit 2024-08-19 08:24:44:
Hello Michael,
On pátek 16. srpna 2024 11:31:15, SELČ Michael J Gruber wrote:
Pavel Raiskup venit, vidit, dixit 2024-08-16 11:06:21:
On čtvrtek 15. srpna 2024 17:02:30, SELČ Michael J Gruber wrote:
Neal Gompa venit, vidit, dixit 2024-08-15 16:14:30:
On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup praiskup@redhat.com wrote:
...
And I really think epel-* makes no sense since it's always "+" to something. EPEL guidelines spell out what is the official base distro for which EPEL (next or what not). That is something we could add next to the respective chroot in copr (just like the current remarks there).
The 'epel-10' chroot in Copr and mock-core-configs makes sense for user's convenience, and I believe we want to have it. That's NB also the default "dnf copr enable" choice on Enterprise Linux machines.
In mock-core-configs probably, because users don't have to look up which config is "for epel-9", e.g., or which release is "rawhide".
But there's a difference betwen mock and copr here:
- If I built in mock f41 (last week) which is a link to rawhide I in fact used the rawhide buildroot etc, not a copy of it. (disttag f41, and methinks rawhide should link to f41, not vice versa, but that's a different issue)
There was no f41 chroot in Copr until now (enabled them ~5 minutes ago, you reminded me to do so, thanks!).
In a local mock build, yes. The latest `mock-core-configs` update https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1 did the change.
- If I build in mock against chroots for linked mock configs I have separate buildroots and builds.
I don't think we want the latter, but I may be wrong.
We do not enable the symlinked chroots in Copr, actually. So this should be fine? I'm not sure I 100% understand your concern, so please elaborate.
Mutual misunderstanding, I guess ;-)
What I meant was the following: Say we have two mock configs A and B which are "the same" (one links to the other), such as:
- fedora-rawhide and fedora-42 (as of now) - epel-7 and centos+epel-7 (now in eol)
Then local builds would use one buildroot for both A and B. OTOH, if copr offers A and B, then this would create 2 chroots and different builds.
I (mis?)-understood your suggestion as having both A and B in copr in such cases. My suggestion was to offer, say, A only (not B) in copr and have "this is the same as B" as a description.
Looking at current state, we have for example: - mock core config: rhel+epel-9 (but no epel-9) - copr: epel-9 with description "Builds are done against RHEL + EPEL." (but no rhel+epel)
So, if A="rhel+epel-9" and B="epel", we have A in mock core config (but not B) and B in copr with description "same as A". I guess it's almost what I suggest (with a mock config link from B to A missing).
Note that the status quo is different for centos-stream-9: - mock core config: centos-stream-9, centos-stream+epel-9, centos-stream+epel-next-9 - copr: centos-stream-9, centos-stream+epel-next-9
Cheers Michael
On pondělí 19. srpna 2024 10:23:09, SELČ Michael J Gruber wrote:
Pavel Raiskup venit, vidit, dixit 2024-08-19 08:24:44:
Hello Michael,
On pátek 16. srpna 2024 11:31:15, SELČ Michael J Gruber wrote:
Pavel Raiskup venit, vidit, dixit 2024-08-16 11:06:21:
On čtvrtek 15. srpna 2024 17:02:30, SELČ Michael J Gruber wrote:
Neal Gompa venit, vidit, dixit 2024-08-15 16:14:30:
On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup praiskup@redhat.com wrote:
...
And I really think epel-* makes no sense since it's always "+" to something. EPEL guidelines spell out what is the official base distro for which EPEL (next or what not). That is something we could add next to the respective chroot in copr (just like the current remarks there).
The 'epel-10' chroot in Copr and mock-core-configs makes sense for user's convenience, and I believe we want to have it. That's NB also the default "dnf copr enable" choice on Enterprise Linux machines.
In mock-core-configs probably, because users don't have to look up which config is "for epel-9", e.g., or which release is "rawhide".
But there's a difference betwen mock and copr here:
- If I built in mock f41 (last week) which is a link to rawhide I in fact used the rawhide buildroot etc, not a copy of it. (disttag f41, and methinks rawhide should link to f41, not vice versa, but that's a different issue)
There was no f41 chroot in Copr until now (enabled them ~5 minutes ago, you reminded me to do so, thanks!).
In a local mock build, yes. The latest `mock-core-configs` update https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1 did the change.
- If I build in mock against chroots for linked mock configs I have separate buildroots and builds.
I don't think we want the latter, but I may be wrong.
We do not enable the symlinked chroots in Copr, actually. So this should be fine? I'm not sure I 100% understand your concern, so please elaborate.
Mutual misunderstanding, I guess ;-)
What I meant was the following: Say we have two mock configs A and B which are "the same" (one links to the other), such as:
- fedora-rawhide and fedora-42 (as of now)
- epel-7 and centos+epel-7 (now in eol)
Then local builds would use one buildroot for both A and B. OTOH, if copr offers A and B, then this would create 2 chroots and different builds.
Indeed.
I (mis?)-understood your suggestion as having both A and B in copr in such cases. My suggestion was to offer, say, A only (not B) in copr and have "this is the same as B" as a description.
Looking at current state, we have for example:
- mock core config: rhel+epel-9 (but no epel-9)
- copr: epel-9 with description "Builds are done against RHEL + EPEL." (but no rhel+epel)
/me nods
So, if A="rhel+epel-9" and B="epel", we have A in mock core config (but not B) and B in copr with description "same as A". I guess it's almost what I suggest (with a mock config link from B to A missing).
Yeah, I think we originally wanted to created the link "by default" but there was a community "agreement on disagreement" on which one should be the default base distro (Alma/CentOS/Oracle/RHEL/Rocky). I think this:
https://pagure.io/epel/issue/133
So instead, we implemented a helper method .. if you run `mock -r epel-8-x86_64 ...` (or epel-9) for the first time on your local machine, it offers you a creation of the desired "B => A" symlink :)
Note that the status quo is different for centos-stream-9:
- mock core config: centos-stream-9, centos-stream+epel-9, centos-stream+epel-next-9
- copr: centos-stream-9, centos-stream+epel-next-9
Indeed, we miss centos-stream+epel-9 in Copr. Not sure it is worth adding to Copr. We don't necessarily add all the combinations, because storage, because maintenance, ...
Pavel
Cheers Michael
On čtvrtek 15. srpna 2024 15:44:26, SELČ Pavel Raiskup wrote:
The epel-8-* and epel-9-* chroots in Fedora Copr are aliases to the "rhel+epel-*" chroots from `mock-core-configs` package. We'd like to have the same approach for `epel-10` once there's a released variant of RHEL 10 GA.
For now though, there's the variant `centos-stream+epel-10` in the new mock-core-configs release, though:
https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1So we could make `epel-10-*` an alias to `centos-stream+epel-10` for the time being, and do the switch to `rhel+epel-10` later on. Do you think this makes sense? Or is it just too early?
As previously discussed, EPEL 10 builds are designed to be built against CentOS Stream 10 + EPEL, so enabling them in Copr right now should bring no inconvenience. I went ahead and enabled epel-10 chroots in Fedora Copr. Feel free to experiment! Testing build:
https://copr.fedorainfracloud.org/coprs/praiskup/test-epel-10/build/7912610/
Enjoy the weekend, and happy building! Pavel
copr-devel@lists.fedorahosted.org
-
Michael J Gruber -
Neal Gompa -
Pavel Raiskup