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. 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.
> > It probably comes from the (misguided) school of thought
> > $Log$ in source files...
I disagree. Adding %changelogs to specs is not any different from $Log$.
Depends on what $Log$ expands to. You can put very useful comments in
there which make a good reading. And everyone without immediate access to
CVS would benefit from such comments, because they are included in source
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