On Tue, Apr 7, 2020 at 2:11 PM Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote: > > On Tue, Apr 7, 2020 at 7:55 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote: > > > > > > Hi, > > > > > > On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > > > > > > > On 07. 04. 20 12:18, Aleksandra Fedorova wrote: > > > > >> 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. > > > > > > > > > > > > What you say here is very inconsistent with %{eln} and %{rhel} value. In > > > > particular "the versioning here should be independent from RHEL" and "we don't > > > > try to link to particular RHEL release" is very weird considering that %{eln} > > > > and %{rhel} will evaluate to "next RHEL version". > > > > > > You are right. Originally we were thinking of %{eln} as a boolean, > > > rather than a meaningful data. So the important part was that we set > > > it to something, so that in those very rare cases where we may want to > > > have a condition based on eln, we can use it. > > > We defined %{eln} to be "something", and that something just happened > > > to be %{rhel}. > > > > > > But since we are talking about versioning for eln now, it makes sense > > > to use this macro to store the actual data about eln buildroot. > > > > > > So I am thinking of adjusting the change in the following form: > > > > > > ---- > > > * %{rhel} will be set and will return a number one higher than the > > > most recent major release of Red Hat Enterprise Linux (at present, > > > that will be 9). > > > * %{eln} will be set and will expand to the ELN version (independent > > > of Fedora and RHEL) in a format "X.Y". X will be bumped for mass > > > rebuilds, Y - for other changes. > > > * %{dist} will be set to "eln%{eln}" > > > > > > Explicit usage of %{eln} macro in spec files should be discouraged. As > > > its main purpose is the versioning of the build environment, not > > > adjusting the sources. > > > ---- > > > > > > This way we can experiment with the configuration ELN-buildroot > > > without bumping package sources. > > > > > > And we will have RHEL versioning available, but not directly, which > > > adds some flexibility in relation between ELN and RHEL. > > > > > > > This definitely solves the issue I've been thinking of. I'm not sure I > > understand why we want to disconnect the ELN version from the upcoming > > RHEL version, even in the DistTag? It seems to be a weird hoop to > > separate when we all know this is about building the next RHEL major, > > and we all know what the next version is, and we all know the > > timelines. > > Don't get me wrong, I am not trying to hide the fact that we are > building RHEL type of packages. > > But > 1) aligning those versions is a more complex task than it looks. > > Historically we had this %rhel macro to map to next release version > working, because we were building Fedora content for RHEL only during > the specific phase of RHEL development, where this number is known and > fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And > it is not that clear when exactly the jump of this version will > happen. Because of the continuity the mapping between eln packages and > RHEL packages is less obvious: It depends on which phase internal RHEL > development is. but more to that, it can depend on which phase the > development of a specific package is, as some packages can diverge > from upstream earlier than others. > > So this eln to rhel mapping is a more complicated topic, then mapping > EPEL to RHEL for example. And we probably will have to rethink it > several times in the next couple of years. > > 2) we may need to bump version of the eln buildroot much more often > than RHEL does major releases. > > As it comes from the use cases and the problem you have described, we > want to actively experiment with the buildroot setup. So it makes > sense to track it through versioning. > Makes some sense to me. I'm a bit skeptical, but the reasoning makes sense. With that adjustment, at least from my perspective I think this is okay. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
