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 <prais...@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
>
>
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
