Hi,
On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok mhroncok@redhat.com 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@lists.fedoraproject.org/...
But I guess we need to extend this conversion by answering:
- versioning of what exactly?
- 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:
- we don't try to link to particular RHEL release;
- 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.
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
-- -- Aleksandra Fedorova bookwar