ambiguity in the guidelines

[Christopher Stone]

On 7/5/06, Christopher Stone <chris.stone at gmail.com> wrote:
> On 7/5/06, seth vidal <skvidal at linux.duke.edu> wrote:
> > On Wed, 2006-07-05 at 16:26 -0700, Christopher Stone wrote:
> > > The way I see it is that Fedora packages and Fedora packagers should
> > > strive to have the best spec files possible.
> > >
> > > If providing a version number in the changelog makes it easier for
> > > users of the package in any way then it should be added to spec files.
> > >
> > > I don't see this as an overloading of a tag issue, I see this as a
> > > packager being lazy issue.  Just my wooden nickle.
> >
> > It's an overloaded tag b/c the tag did not originally have that intent.
> >
> > it's an added bullshit item that clutters up the data.
>
> It's not bullshit.  I have myself used rpm -q --changelog to find out
> which changes were made for a particular version.
>
> It should not be required, because you should be able to add entries
> to the change log without a release, such as changes only made in cvs.
>  But when you do an actual release you should match the date with the
> release number to make it easier for users to associate dates with
> releases.
>
> Yes you can argue that rpm should do this automatically somehow, but
> where is this rpm patch that you have been working on?  I think it is
> not unreasonable to ask packagers to place version numbers on
> changelog entries that are associated with a release.  This provides a
> common courtesy to those using the rpm.
>
> We understand your point that it is redundant information, but I think
> the better solution is to provide a source patch to fix rpm, or file a
> bug against rpm and place the extra information in the changelog in
> the meantime.
>

BTW if you decide to patch rpm (somehow) it would have to be tied into
the official build system so that rpm actually knows that it is doing
a release for this particular changelog entry.  Or else we would have
to require that every changelog entry be associated with a release
which I don't think is a good idea.

Basically my point is that it is courtesy to add this historical
information in the spec file.  It is a lot easier for a user to find
the information he needs.  If you have some type of egregious hack in
your spec file do you add a comment explaining the hack or do you
leave out all comments in your spec files because they are not
required information?  A comment is afterall redundant information as
anyone should be able to reverse engineer your hack to determine why
it is there.