On 03.02.2009 13:27, Manuel Wolfshant wrote:
I would like to hear some more opinions on the subject described
in
the thread started by
https://bugzilla.redhat.com/show_bug.cgi?id=481601#c6. My opinion is
expressed in comment #9 and I am quite sure that any future update of
the rawhide version might introduce the exact same problem again.
I'd tend to agree with some of what the reported outlines, but I'd say
it's not important enough to justify a rebuild.
I
could, of course, keep using always the same release tag as in the
corresponding rawhide version, but it looks a bit odd to me.
For me it's not odd; I'd even say it's the natural thing to do.
Rawhide is the main "devel branch" for the spec file itself -- the
version-release of the spec file for me is like a verison number of a
regular software. Version numbers don't go backwards; thus if I'd (kind
of) fork a spec file by picking it from rawhide and using it for another
branch (EPEL in this case) then I'd normally leave the version-release
as it is as long as %dist gets used in %release.
But if maintainers in Rawhide and EPEL are different then I'd want to be
on the safe site and would add a ".1" to %release and "rebuild for
EPEL"
to the changelog -- then it's obvious where this spec file exactly comes
from and how they relate to each other -- that might be important to
know for users and packagers.
CU
knurd