[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ambiguity in the guidelines



On 7/5/06, Christopher Stone <chris stone gmail com> wrote:
On 7/5/06, seth vidal <skvidal 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]