Re: Fedora 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)
On Tue, Feb 16, 2021 at 9:39 AM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Tue, Feb 16, 2021 at 3:01 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>
> On 16. 02. 21 14:48, Fabio Valentini wrote:
> > if version_at(commit) != last_version:
> > return 0
>
> Should this be "return 1"?
No, 0 is correct. If the version does not match, this is the last
commit *before* a version update.
The "max(parents) + 1" then sets the Release to 1 for the commit that
actually changed the version :)
> To prevent accidental divergence between the git history and the build system.
> That's why this information is only used in the koji plugin, locally (ie: via
> the rpmautospec CLI) it only relies on the git tags.
So ... you want to *prevent* divergence by *introducing* divergence? I
do not follow ...
> Using the number of commits can give weird results with merge commits and even
> though the upgrade path is not really an issue anymore, we preferred to try
> preserving it. So rpmautospec should minimize the risk of broken upgrade path.
That is possible. However, I assume it's possible to determine whether
a given commit is a merge commit? Then it would be easy to skip over
those in the computation.
And while I agree that upgrade path should be clean, fixing those
corner cases by making the whole process brittle and possibly
inconsistent does not sound like a good idea to me. And with system
upgrade tools defaulting to `distro-sync` mode now, this corner cases
are even less of a problem.
It's a problem in the normal upgrade case, since people release
post-release updates this way too.
--
真実はいつも一つ！/ Always, there's only one truth!