On Thu, 27 Feb 2020 at 09:53, Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
>
> On 27. 02. 20 9:20, Pierre-Yves Chibon wrote:
> >> How would that work with "complex" releases? For example release containing
> >> prerelease info like 0.1.beta.2 or 0.1.20120225gitd6c789a? Many Go package
> >> have no version, so depend heavily on the Release tag to signal what is the
> >> snapshot date and git commit packaged.
> > This is something that we will need to investigate and clarify a little more,
> > the answer may very well be: it won't, but let's investigate this first.
>
> There are three ways of of there I can think of ATM:
>
> 1. (as said by Pierre) make it opt-in only and don't handle this
> 2. (as said by Neal) don't do this, use 0.1~beta.2-<release>
> 3. allow to keep the Release filed if it uses %{baserelease}
>
> %{baserelease} is already respected by rpmdev-bumpspec (and hence mass rebuilds)
>
>
> %global baserelease 8
> Release: iamcrazy1234568andIknowit.%{baserelease}.whatnot~foo666%{?dist}
>
> bumpspec does:
>
> %global baserelease 9
> Release: iamcrazy1234568andIknowit.%{baserelease}.whatnot~foo666%{?dist}
>
> So we can reuse that and say: If the Release is manually defined in spec and
> uses %{baserelease} and %{baserelease} is not defined in spec, the automation
> sets the %{baserelease} value instead of setting the release directly.
Hello Miro,
interesting idea. I have some notes:
If i understand correctly, this would rely on the locally undefined
%{baserelease} macro, which is later provided auto-magically by the
build system. Should this macro be populated also locally if not
defined?
I already mentioned it earlier in this thread but I think the use of
bare rpm macro is problematic because they either need to have git
context (metadata) around to evaluate or they would even need to do
remote network requests. Do you disagree?
But anyway, what packager provides statically in the Release filed
without using a dedicated macros should imho stay there and not be
somehow magically deleted and overridden by build system. So the
solution might be simply:
Release: beta.2.<<dynamic_release_part>>
or it might be:
Release: <<dynamic_release prefix=beta.2>>
if the macro for the release computation needs to know the value of
the static prefix (that would be the case for git_release macro
defined in rpkg-util).
>
> --
> 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
_______________________________________________
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
