On Sat, Nov 2, 2013 at 9:04 PM, Michael Schwendt <mschwendt@xxxxxxxxx> 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_bumps_for_old_branches
>> > (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] https://bitbucket.org/dridi/fedora_packages/downloads/numatop-el6.spec
> --
> devel mailing list
> devel@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
