ambiguity in the guidelines

[Mihai Ibanescu]

On Thu, Jul 06, 2006 at 12:13:06AM -0700, Christopher Stone wrote:
> On 7/5/06, seth vidal <skvidal at linux.duke.edu> wrote:
> >Let's be clear about what's going on here:
> >1. I do not think it is an appropriate to overload the field
> >2. I do not wish to take part in that particular dirtiness
> >3. until today no one has questioned the desire for correctness on my
> >part
> >4. I'm not asking anyone else to do what I'm doing - I'm just trying to
> >do what I think is most correct and appropriate given the technology
> >available.
> 
> Okay, but you have not explained _why_ adding version information to
> this field is "overloading" it.
> 
> How does this affect anything?  You have not given any reason to not
> include version information other than the name of the field which if
> I recall from this thread is called "changelogname".
> 
> So why is this important to not include version information in this
> field?  Why is it important that this field only contain date,
> packager name and email?  Is there some technical reason why this
> field should only contain this particular data?
> 
> What if we called the field "changeloginfo" rather than
> "changelogname" or whatever it is called now? Would this change things
> in your mind?

For completeness' sake, rpm does parse changelog entries, and stores it in 3
fields: RPMTAG_CHANGELOGTIME, RPMTAG_CHANGELOGNAME and RPMTAG_CHANGELOGTEXT

In an entry:

* Thu Jul  6 2006 Mihai Ibanescu <misa at redhat.com> foo bar
- this is the text

rpm will enforce the format of the first line to be a valid date, and will
store it in RPMTAG_CHANGELOGTIME. Everything from the first line after that is
stored in RPMTAG_CHANGELOGNAME.

The next lines are stored in RPMTAG_CHANGELOGTEXT.

Seth's argument is that, if we want to enforce the format of the entry, then
we should create another header field and parse the extra data accordingly.

Several years ago, in RHN, we tried to compute some statistics on how many
entries were edited by a particular packager, and I found out the hard way that
you can't quite rely on the contents of RPMTAG_CHANGELOGNAME. Sure, you can
parse that data somehow. But who guarantees (without running some tests on all
core + extras packages) that the name itself is parseable by a regex? Even the
not-so-standard "misa at redhat dot com" shouldn't have been left in by RPM,
imo. If you want privacy, register a yahoo account and use that for packaging
(of course nobody would trust you - but I digress).

rpm's rules are way too loose, and people have taken advantage of them in all
sorts of ways. Enforcing rules should start with making rpm consistent first.

I do find the version information extremely useful in the changelogs, but I
agree with Seth we should do it right as opposed to taking advatage of rpm's
spec parser.

Misa