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@xxxxxxxxxx> 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 -- _______________________________________________ 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
