Bug 197699

How reproducible:
rpmlint yum-utils-0.6-2.fc5.noarch.rpm
W: yum-utils no-version-in-last-changelog

I won't fix the above. I do not think that version numbers should overload that
field in the changelog. 

E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/fastestmirror/CVS/Root
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/versionlock/CVS/Root

I'll get all the CVS repo stuff cleaned up - thanks.


W: yum-utils wrong-file-end-of-line-encoding
/usr/share/doc/yum-utils-0.6/plugins/tsflags/tsflags.py

this is a horse-shit warning from rpmlint.

(In reply to comment #1)
> How reproducible:
> rpmlint yum-utils-0.6-2.fc5.noarch.rpm
> W: yum-utils no-version-in-last-changelog
> 
> I won't fix the above. I do not think that version numbers should overload that
> field in the changelog. 
What gives you the priviledge to do so? You are clearly violating the packaging
guidelines.

Red-hot hatred for misuse of resources.

:)

oh and the guidelines don't SAY that.

they say:

Changelogs

Every time you make changes, that is, whenever you increment the E-V-R of a
package, add a changelog entry. This is important not only to have an idea about
the history of a package, but also to enable users, fellow packages, and QA
people to easily spot the changes that you make.

If a particular change is related to a Bugzilla bug, include the bug ID in the
changelog entry for easy reference, e.g.

* Wed Jun 14 2003 Joe Packager <joe at gmail.com> - 0:1.0-0.fdr.2
- Added README file (#42).


It doesn't say you must overload the field.

Well, though I technically largely agree with you that changelogs are not of
much use, your package would have failed review because of you not using correct
changelog.

I.e. to me this is a clear case of a FPB and FESCOs member abusing his position
to circumvent the "rules of the games", all others have been urged to obey.

Ralf, the guidelines themselves do not support your position.  They state you
must have a changelog, not that the changelog MUST adhere to the format shown. 
IMHO that is maintainer descretion.  rpmlint gives it a warning, not an error. 
While I would prefer that the version is there, just to easily match up changes
to versions, the date itself helps in this regard.

So, if you have a problem with this, bring it up to the packaging committee to
try and set policy regarding the format of changelogs.

(In reply to comment #6)
> Ralf, the guidelines themselves do not support your position.  They state you
> must have a changelog, not that the changelog MUST adhere to the format shown.

My understanding of this is different. rpmlint enforces my understanding and
forcing changelogs on packagers has been common practice during reviews for a
very long time. IMO, you are twisting words.

There is a changelog in the package.

Just not one tagged with the version number of the package overloading the field
used for the changelog entry author.

No, I'm not Ralf.  You are confusing the difference between a changelog entry,
and the format of said changelog entry.  Of course we enforce a changelog. 
However rpmlint just warns if there is no version-release in the changelog
entry.  The guidelines state that a changelog must be there, they do NOT however
dictate what the format should be.

Just to be clear, a changelog entry is infact a must.  The FORMATTING of said
entry is not defined nor enforced.