Hey all,
Been toying with the idea of splitting the changelog out of the kernel spec itself, to reduce the size of the spec file. Basically, instead of %changelog followed by all the entries, it'd be %include %{SOURCE1}, which is a file 'fedora-kernel-changelog', which carries all the usual changelog entries. Its reasonably trivial to implement, though my current hack-around for 'make clog' complains about me redefining the clog target. Is shaving 800+ lines out of the spec file (only to put them in another file) worth the hassle though?
On Mon, Aug 18, 2008 at 01:13:26PM -0400, Jarod Wilson wrote:
Hey all,
Been toying with the idea of splitting the changelog out of the kernel spec itself, to reduce the size of the spec file. Basically, instead of %changelog followed by all the entries, it'd be %include %{SOURCE1}, which is a file 'fedora-kernel-changelog', which carries all the usual changelog entries. Its reasonably trivial to implement, though my current hack-around for 'make clog' complains about me redefining the clog target. Is shaving 800+ lines out of the spec file (only to put them in another file) worth the hassle though?
Probably not until we move away from CVS to an SCM that doesn't suck. It'd be nice if 'make build' slurped the changelog out of the SCM.
Dave
Dave Jones wrote:
On Mon, Aug 18, 2008 at 01:13:26PM -0400, Jarod Wilson wrote:
Hey all,
Been toying with the idea of splitting the changelog out of the kernel spec itself, to reduce the size of the spec file. Basically, instead of %changelog followed by all the entries, it'd be %include %{SOURCE1}, which is a file 'fedora-kernel-changelog', which carries all the usual changelog entries. Its reasonably trivial to implement, though my current hack-around for 'make clog' complains about me redefining the clog target. Is shaving 800+ lines out of the spec file (only to put them in another file) worth the hassle though?
Probably not until we move away from CVS to an SCM that doesn't suck. It'd be nice if 'make build' slurped the changelog out of the SCM.
I stupidly left out the part where I was supposed to mention that what I had in mind longer-term was that it'd be more straight-forward to manipulate a stand-alone changelog, esp. if we could just dump the changelog out of our SCM. (Some of what Don and Vivek are doing for RHEL w/git is what motivated me in the first place).
We could also, if so desired, install the split-out changelog as a %doc file, the thought being that not everyone knows to look at 'rpm -q --changelog' output or look in the srpm/cvs/etc to see what's changed.
John W. Linville wrote:
I don't see how. What is the motivation?
Apologies, see above. :)
On Mon, Aug 18, 2008 at 7:41 PM, Jarod Wilson jwilson@redhat.com wrote:
We could also, if so desired, install the split-out changelog as a %doc file, the thought being that not everyone knows to look at 'rpm -q --changelog' output or look in the srpm/cvs/etc to see what's changed.
This would just confuse user and is inconsistent with the rest of the distro...
On Mon, Aug 18, 2008 at 07:43:49PM +0200, drago01 wrote:
On Mon, Aug 18, 2008 at 7:41 PM, Jarod Wilson jwilson@redhat.com wrote:
We could also, if so desired, install the split-out changelog as a %doc file, the thought being that not everyone knows to look at 'rpm -q --changelog' output or look in the srpm/cvs/etc to see what's changed.
This would just confuse user and is inconsistent with the rest of the distro...
I presume the rpm command would still work, so I would see no harm in adding the changelog as a %doc (if/when it is broken-out from the spec file).
John
John W. Linville wrote:
On Mon, Aug 18, 2008 at 07:43:49PM +0200, drago01 wrote:
On Mon, Aug 18, 2008 at 7:41 PM, Jarod Wilson jwilson@redhat.com wrote:
We could also, if so desired, install the split-out changelog as a %doc file, the thought being that not everyone knows to look at 'rpm -q --changelog' output or look in the srpm/cvs/etc to see what's changed.
This would just confuse user and is inconsistent with the rest of the distro...
How so?
I presume the rpm command would still work
Correct.
so I would see no harm in adding the changelog as a %doc (if/when it is broken-out from the spec file).
Just to be clear... To make sure its 100% clear which kernel the changelog matches up with, it'd have to be %doc'd for each kernel and kernel-flavour, so it winds up in /usr/share/doc/kernel%{?flavour:-%{flavour}}-%{version}. If its part of kernel-doc, I think its not always obvious which actual kernel package it matches.
With those clarifications, I don't see how it'd be confusing, or how it would cause any meaningful consistency problems with other distros. But please do enlighten me if I'm missing something. :)
On Mon, Aug 18, 2008 at 8:09 PM, Jarod Wilson jwilson@redhat.com wrote:
John W. Linville wrote:
On Mon, Aug 18, 2008 at 07:43:49PM +0200, drago01 wrote:
On Mon, Aug 18, 2008 at 7:41 PM, Jarod Wilson jwilson@redhat.com wrote:
We could also, if so desired, install the split-out changelog as a %doc file, the thought being that not everyone knows to look at 'rpm -q --changelog' output or look in the srpm/cvs/etc to see what's changed.
This would just confuse user and is inconsistent with the rest of the distro...
How so?
Ignore me .. read that as "move the changelog out of the rpm"
On Mon, Aug 18, 2008 at 01:20:05PM -0400, Dave Jones wrote:
On Mon, Aug 18, 2008 at 01:13:26PM -0400, Jarod Wilson wrote:
Hey all,
Been toying with the idea of splitting the changelog out of the kernel spec itself, to reduce the size of the spec file. Basically, instead of %changelog followed by all the entries, it'd be %include %{SOURCE1}, which is a file 'fedora-kernel-changelog', which carries all the usual changelog entries. Its reasonably trivial to implement, though my current hack-around for 'make clog' complains about me redefining the clog target. Is shaving 800+ lines out of the spec file (only to put them in another file) worth the hassle though?
Probably not until we move away from CVS to an SCM that doesn't suck. It'd be nice if 'make build' slurped the changelog out of the SCM.
Dave
I suppose that you could make the argument that including the changelog at all isn't really needed if you have it properly stored in scm. i.e if we used git the way the rhel trees are handled, and auto-generate patches based on commits, all we would really need to do is mark the base tree that we started from and the final tag that we're building, and you could extract the changelog at your leisure
Neil
-- http://www.codemonkey.org.uk
Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
kernel@lists.fedoraproject.org
-
Dave Jones -
drago01 -
Jarod Wilson -
John W. Linville -
Neil Horman