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