On 7/5/06, seth vidal <skvidal@xxxxxxxxxxxxxx> wrote:
On Wed, 2006-07-05 at 19:21 -0700, Christopher Stone wrote:
> On 7/5/06, seth vidal <skvidal@xxxxxxxxxxxxxx> 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 phy.duke.edu>
- 3.4-1%{?dist}.0
- made life miserable for users
* Tue May 31 2005 Seth Vidal <skvidal at phy.duke.edu>
- 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 phy.duke.edu>
** 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
"overloaded").
It seems to me from this argument that it really is basically a
laziness issue. Trying to claim it will "intentionally make others
suffer".
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.
