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 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. 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 tarballs. > 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.
