Hi, Neal,
On Tue, Apr 7, 2020 at 12:49 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
>
> On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
> >
> >
> >
> > On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
> >>
> >> * The DistTag should be versioned. Either .eln.elX (e.g. .eln.el9),
> >> .elnX (e.g. .eln9), or just plain .elX (e.g. .el9).
> >> * Likewise, I think the Koji tags should be versioned too.
> >>
> >> I've personally been burned enough times by not having versioned
> >> DistTags for personal rebuilds that I would strongly suggest you
> >> reconsider having unversioned ones.
> >
> > Would you mind explaining some of the situations in which you were burned? I’m not ruling this out, but I’d like a clear justification if we were to change something.
> >
>
> So, prior to me building my packages in OBS and getting auto-bumping
> Releases, I used to bump into issues all the time with building
> openSUSE packages in an environment like Koji's, where the NVR is the
> key for a unique package. openSUSE does *not* define a DistTag or the
> %dist variable, so %{?dist} evaluates to nothing. If you're doing
> rebuilds of your packages with no source changes from one release of
> openSUSE to the next, or rebuilding for new Tumbleweed snapshots,
> you're going to get collisions all the time, and builds will just fail
> because the NVR already exists.
>
> This is utter chaos and you *really* don't want that problem on your
> hands. Having the freedom to do a rebuild cycle for ELN whenever you
> want to rebootstrap to a new major without changing sources is a
> hugely valuable thing to be able to do.
>
> And honestly, I expect the ELN tree to exist for a long time once it's
> in Fedora. So some of this is also planning for a future where we
> always have Fedora ELN along with Rawhide and regular Fedora stable
> releases.
>
> What I'm confused about is the hangup with versioning the ELN tree.
> Why is this a problem?
I explained it in one of the previous threads:
https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/
But I guess we need to extend this conversion by answering:
1) versioning of what exactly?
2) versioning by which number?
>From the problem you describe, it looks like the solution for it is to
have %{?dist} resolved to a versioned data. But the versioning here
should be independent from both RHEL and Fedora versioning. It should
be based on changes in eln buildroot configuration itself: As soon as
we want to have a non-disruptive rebuild in eln buildroot, we
increment the number in %{?dist} for eln, and rebuild the same srpm.
And this action is not linked to Fedora or RHEL releases. This number
may as well be the date, or a simple counter.
If we do versioning in this way, then it resolves both concerns I had
in my reply there:
1) we don't try to link to particular RHEL release;
2) we don't version the koji tag and target, and we don't need to
update Koji configuration every time Fedora creates a branch. Thus the
pipelines we create for building eln packages can still be
unversioned.
> >
> >>
> >> Finally, there is no adequate explanation for why ELN content can't go
> >> out to the mirrors like Rawhide content does. I'd vastly prefer that
> >> simply to have similar levels of availability as consumers of ELN
> >> content. I would prefer seeing it go to the mirror network like
> >> everything else.
> >
> >
> >
> > It’s not so much that it *cannot* as that we are trying not to overload the mirror network with content not useful to non-developers.
> >
>
> Unless you plan to get Red Hat to do CDN delivery of ELN, I think
> you're going to want it on the mirror network anyway. Ultimately,
> contributors like myself need to be able to *use* the content, and not
> having it delivered via the mirror network means that it's going to be
> painful for a large cross-section of contributors and developers.
>
--
Aleksandra Fedorova
bookwar
_______________________________________________
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
