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. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > _______________________________________________ > 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 -- -- 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
