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@xxxxxxxxxx> 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.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? > > > > > > > > > > > > > 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 > >
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
