Bug 197699 - Bad packaging
Bad packaging
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: yum-utils (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-05 12:21 EDT by Ralf Corsepius
Modified: 2013-01-09 22:59 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-05 14:54:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ralf Corsepius 2006-07-05 12:21:29 EDT
Description of problem:
This package is quite badly packaged

Version-Release number of selected component (if applicable):
0.6-2.fc5

How reproducible:
rpmlint yum-utils-0.6-2.fc5.noarch.rpm
W: yum-utils no-version-in-last-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
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/tsflags/CVS/Repository
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/fedorakmod/CVS/Repository
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/versionlock/CVS/Entries
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/fastestmirror/CVS/Repository
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/downloadonly/CVS/Entries
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/fedorakmod/CVS/Entries
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/protectbase/CVS/Root
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/kernel-module/CVS/Entries
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/tsflags/CVS/Entries
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/versionlock/CVS/Repository
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/CVS/Root
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/kernel-module/CVS/Repository
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/downloadonly/CVS/Repository
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/protectbase/CVS/Repository
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/changelog/CVS/Repository
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/changelog/CVS/Entries
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/tsflags/CVS/Root
W: yum-utils wrong-file-end-of-line-encoding
/usr/share/doc/yum-utils-0.6/plugins/versionlock/versionlock.py
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/CVS/Repository
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/fedorakmod/CVS/Root
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/kernel-module/CVS/Root
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/downloadonly/CVS/Root
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/fastestmirror/CVS/Entries
W: yum-utils wrong-file-end-of-line-encoding
/usr/share/doc/yum-utils-0.6/plugins/tsflags/tsflags.py
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/protectbase/CVS/Entries
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/CVS/Entries
E: yum-utils version-control-internal-file
/usr/share/doc/yum-utils-0.6/plugins/changelog/CVS/Root
Comment 1 Seth Vidal 2006-07-05 12:34:09 EDT
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.
Comment 2 Ralf Corsepius 2006-07-05 12:47:37 EDT
(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.
Comment 3 Seth Vidal 2006-07-05 12:50:49 EDT
Red-hot hatred for misuse of resources.

:)

Comment 4 Seth Vidal 2006-07-05 12:57:05 EDT
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.

Comment 5 Ralf Corsepius 2006-07-05 14:54:01 EDT
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.

Comment 6 Jesse Keating 2006-07-05 15:15:51 EDT
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.
Comment 7 Ralf Corsepius 2006-07-05 15:40:19 EDT
(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.



Comment 8 Seth Vidal 2006-07-05 15:58:58 EDT
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.

Comment 9 Jesse Keating 2006-07-05 16:01:15 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.