On Sat, Nov 2, 2013 at 9:04 PM, Michael Schwendt <mschwendt(a)gmail.com> wrote:
On Sat, 02 Nov 2013 19:39:38 +0100, Xose Vazquez Perez wrote:
> Kevin Kofler wrote:
>
> > Xose Vazquez Perez wrote:
> >> BAD use of %{dist} tag(75):
> >> ==========================
> >> afpfs-ng-0.8.1-13.fc21.3.src.rpm 13.fc21.3
> > [and many similar examples]
> >
> > NOTABUG:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_b...
> > (the next paragraph right after the one you linked to).
>
> _rawhide_ is not an *old branch* . And it never was.
>
> To have {?dist}.X in rawhide should be impossible.
>
> It breaks the laws of thermodynamics!!
It looks ugly, but it's harmless.
It's the package maintainer's responsibility to _reset_ the Release tag in
Rawhide when upgrading the Version or when touching the package.
With the example of afpfs-ng, look what has happened here:
http://koji.fedoraproject.org/koji/packageinfo?packageID=8023
Two minor release bumps have been kept, have survived several mass-rebuilds,
because the bump-script does not mess with the Release tag, and even in
a later update by a packager a week ago, the ".3" has not been dropped.
If anyone feels like adding an option to rpmdev-bumpspec, that one could
attempt at cleaning up Release tags -- but note that even least-significant
stuff right of the dist tag could be wanted by the package owner(s), so
simply dropping it might be wrong. E.g. sometimes it's a patchlevel number,
with no "pl" prefix.
I took a quick look at the code because I had a related issue, and
found that rpmdev-bumpspec offers a workaround. If the release tag is
too complicated, you can extract the "bumpable" part into a
'baserelease' macro.
This is what I've done [1] for a package to handle the epel '0.'
prefix mentioned in the guidelines.
Dridi
[1]