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