Hi,
On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok <mhroncok(a)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.o...
>
> 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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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