Le 2020-02-27 09:52, Miro Hrončok a écrit :
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}
Go (and other) packages do not set Version nor Release. They set
distprefixNUMBER, which is defined in
https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/fedora-re...
This automation must be kept or migrated to something else if people do
not want to keep it ("just write bogus upstream versions manually is not
a forward path)
If changelog is automated, distprefixNUMBER should end up somewhere in
it, because that’s important information not present in Version
https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/fedora-re...
also defines some things equivalent to a distpostfix. They probably
belong in changelog too.
Regards,
--
Nicolas Mailhot