ambiguity in the guidelines

Christopher Stone chris.stone at
Thu Jul 6 05:50:06 UTC 2006

On 7/5/06, seth vidal <skvidal at> wrote:
> On Wed, 2006-07-05 at 19:21 -0700, Christopher Stone wrote:
> > On 7/5/06, seth vidal <skvidal at> wrote:
> > > On Wed, 2006-07-05 at 18:58 -0700, Christopher Stone wrote:
> > >
> > > > 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.
> > >
> > > I never said it was redundant info. I said it was in the wrong place, in
> > > an overloaded field.
> >
> > So are you suggesting that the changelog section be broken up into
> > different fields?  If it is just a field name you are concerned about
> > you could break the changelog line into seperate fields and call each
> > field by a different name.
> >
> > Do you agree that historical release information is useful to have
> > available from an rpm query command?
> sure - but it's in the wrong place - put it in the text field of the
> changelog if you MUST have it.
> ie:
> * Wed Jun  1 2005 Seth Vidal <skvidal at>
> - 3.4-1%{?dist}.0
> - made life miserable for users
> * Tue May  31 2005 Seth Vidal <skvidal at>
> - 3.4-1%{?dist}.0
> - intentionally made others suffer.
> etc, etc, etc.
> that way we've left the changelogname field alone and you still have
> your precious version data in each entry.
> Ideally I'd prefer if it were:
> * Tue May 31 2005 Seth Vidal <skvidal at>
> ** Version: 3.4-1%{?dist}.0
> - comment here
> - comment there
> or some such thing.

Actually I was thinking more along the lines of just splitting the
line by parsing it as "Date spec \b name <email spec>  \b version
spec" using some perl regular expression and then sending the pieces
to the appropriate variable names.  (Not that this is even technically
needed for anything right now, but atleast you won't feel this name is

It seems to me from this argument that it really is basically a
laziness issue.  Trying to claim it will "intentionally make others

Why not try to make your spec file as useful as possible?  I have seen
packagers refuse to add %{?dist} tags to their spec file because its
not "a bug".  Well so what?  If it makes it a better spec file why not
add it?  Do these packagers refuse to do these things because of ego
or laziness or some other reason?

If anyone here finds any way to improve upon my packages I am more
than happy to oblige.  I want my spec files to be the best they can be
and I don't mind spending a little extra effort to achieve that goal.

More information about the Fedora-maintainers mailing list