radical suggestion for fc4 release

[Ralf Corsepius]

On Tue, 2005-02-01 at 13:00 +0100, Michael Schwendt wrote:
> On Tue, 01 Feb 2005 12:13:27 +0100, Ralf Corsepius wrote:
> 
> > On Tue, 2005-02-01 at 11:40 +0100, Michael Schwendt wrote:
> > > On Mon, 31 Jan 2005 18:01:57 -0500, Dimitrie O. Paun wrote:
> > > 
> > > > On Mon, Jan 31, 2005 at 05:37:29PM -0500, Eric S. Raymond wrote:
> > > > > Oh, no.  *Bad* idea.  It's an attack on the symptom, not the problem.
> > > > 
> > > > No, it's a *good* idea IMO. Problem is it does't go all the way.
> > > > WTH are changelogs doing in .spec files?!?  This is the job of the version 
> > > > control system, not of packaging specifications.
> > > 
> > > Uhm, they document package changes.
> > Do you document your changes inside of the source code?
> > In my understanding, *specs are one part of rpm's sources.
> 
> With RPM there is no other place where you can document package changes
> and make the same document appear also in the binary rpms.
A matter of design and policy ... this is fedora-devel@ ... so to me
your sentence is nothing but evidence for a deficiency either in rpm's
implementation or RH's policy ...
 
>  It is a matter
> of convenience. You can download a package, take a look at the package
> changes, then extract the ChangeLog file, if included, and if you want to
> look at software changes, too. The spec changelog is even more important
> when already installed software doesn't work as expected and you need
> access to the package changelog quickly.
No, you are missing up a package's contents ChangeLog with the rpm's changelog.

The only reason to look into an rpm's changelog is to find answers
questions related to "Why has this rpm been released?".
Normally you won't find answers to "What has changed inside of the
package's contents."

> > > > It probably comes from the (misguided) school of thought that includes 
> > > > $Log$ in source files...
> > >  
> > > No.
> > I disagree. Adding %changelogs to specs is not any different from $Log$.
> 
> Depends on what $Log$ expands to.
Here you say it: It's all about packaging policy.

Seth said he wants to feed rss from rpm changelogs, and wants to reduce
the size of changelog entries in other.xml, you want to see the
changelogs from the rpm, I don't see any use for changelog histories.

=> Implement a reasonable %changelog policy.

E.g. Add only those %changelogs to an rpm.spec that reach back to the
preceding release and remove everything else.

Frankly speaking, the only situation I have found rpm.specs useful
sofar, was to dig out the responsible maintainer of a package to get in
direct contact to him.

Using a dedicated rpm-header for this purpose (e.g. packager) would seem
much more reasonable to me, but I am not in a position to change RH nor
to enforce this policy.

> > Having an entry in an rpm-header containing the last change might be
> > useful for users being interested in the reason for a new rpm release,
> > but I fail to understand why having a full %changelog-history inside of
> > rpms or metadata files is useful.
> 
> Because not seldomly there are several package revisions between the "new
> rpm release" and the previous one. For instance, during steps from FC3 to
> FC4.
Again, this is just a matter of policy. 

Ralf