The attached patch switches the kernel rpm over from including the current static kernel-*.config files to instead including the config-* files that are actually in cvs.
It means we don't leave kernel-*.config droppings all over the place (following a rebase, its entirely too easy to end up with kernel-2.6.21-*.config and kernel-2.6.22-*.config files laying about, which can sometimes cause odd things to happen), and we don't modify SOURCE files in %prep (see bug 232602), which could otherwise result in repacking an srpm with the same n-v-r with different kernel-*.config files. As a bonus, along the way, this cleans up a number of rpmlint warnings (though there are still a TON to poke at).
In the future, this would also make life easier for the RHEL6 and later maintainers, as we typically prefer config changes against the config-* files, rather than against the kernel-*.config files, but (most) non-rh folks don't have cvs access to get at the config-* files right now.
Thus far, the only real downside is that it requires moving all the config-* files up to the root of the kernel cvs dir, which is 1) a bit messy and 2) results in losing prior versioning history on those files, since cvs blows.
(For the record, I've also done a number of successful builds w/this patch now.)
Comments appreciated!
On 07/11/2007 01:37 PM, Jarod Wilson wrote:
The attached patch switches the kernel rpm over from including the current static kernel-*.config files to instead including the config-* files that are actually in cvs.
It means we don't leave kernel-*.config droppings all over the place (following a rebase, its entirely too easy to end up with kernel-2.6.21-*.config and kernel-2.6.22-*.config files laying about, which can sometimes cause odd things to happen), and we don't modify SOURCE files in %prep (see bug 232602), which could otherwise result in repacking an srpm with the same n-v-r with different kernel-*.config files. As a bonus, along the way, this cleans up a number of rpmlint warnings (though there are still a TON to poke at).
In the future, this would also make life easier for the RHEL6 and later maintainers, as we typically prefer config changes against the config-* files, rather than against the kernel-*.config files, but (most) non-rh folks don't have cvs access to get at the config-* files right now.
Thus far, the only real downside is that it requires moving all the config-* files up to the root of the kernel cvs dir, which is 1) a bit messy and 2) results in losing prior versioning history on those files, since cvs blows.
1) No big deal, though.
2) There's not much relevant history in there anyway.
Chuck Ebbert wrote:
On 07/11/2007 01:37 PM, Jarod Wilson wrote:
The attached patch switches the kernel rpm over from including the current static kernel-*.config files to instead including the config-* files that are actually in cvs.
It means we don't leave kernel-*.config droppings all over the place (following a rebase, its entirely too easy to end up with kernel-2.6.21-*.config and kernel-2.6.22-*.config files laying about, which can sometimes cause odd things to happen), and we don't modify SOURCE files in %prep (see bug 232602), which could otherwise result in repacking an srpm with the same n-v-r with different kernel-*.config files. As a bonus, along the way, this cleans up a number of rpmlint warnings (though there are still a TON to poke at).
In the future, this would also make life easier for the RHEL6 and later maintainers, as we typically prefer config changes against the config-* files, rather than against the kernel-*.config files, but (most) non-rh folks don't have cvs access to get at the config-* files right now.
Thus far, the only real downside is that it requires moving all the config-* files up to the root of the kernel cvs dir, which is 1) a bit messy and 2) results in losing prior versioning history on those files, since cvs blows.
No big deal, though.
There's not much relevant history in there anyway.
My thoughts exactly.
(Hell, I'd even like to 'mv kernel-2.6.spec kernel.spec', but davej seems to not like that idea so much... ;)
On Wed, 2007-07-11 at 16:49 -0400, Jarod Wilson wrote:
Chuck Ebbert wrote:
On 07/11/2007 01:37 PM, Jarod Wilson wrote:
The attached patch switches the kernel rpm over from including the current static kernel-*.config files to instead including the config-* files that are actually in cvs.
It means we don't leave kernel-*.config droppings all over the place (following a rebase, its entirely too easy to end up with kernel-2.6.21-*.config and kernel-2.6.22-*.config files laying about, which can sometimes cause odd things to happen), and we don't modify SOURCE files in %prep (see bug 232602), which could otherwise result in repacking an srpm with the same n-v-r with different kernel-*.config files. As a bonus, along the way, this cleans up a number of rpmlint warnings (though there are still a TON to poke at).
In the future, this would also make life easier for the RHEL6 and later maintainers, as we typically prefer config changes against the config-* files, rather than against the kernel-*.config files, but (most) non-rh folks don't have cvs access to get at the config-* files right now.
Thus far, the only real downside is that it requires moving all the config-* files up to the root of the kernel cvs dir, which is 1) a bit messy and 2) results in losing prior versioning history on those files, since cvs blows.
No big deal, though.
There's not much relevant history in there anyway.
My thoughts exactly.
(Hell, I'd even like to 'mv kernel-2.6.spec kernel.spec', but davej seems to not like that idea so much... ;)
Why?
josh
Josh Boyer wrote:
On Wed, 2007-07-11 at 16:49 -0400, Jarod Wilson wrote:
Chuck Ebbert wrote:
On 07/11/2007 01:37 PM, Jarod Wilson wrote:
The attached patch switches the kernel rpm over from including the current static kernel-*.config files to instead including the config-* files that are actually in cvs.
It means we don't leave kernel-*.config droppings all over the place (following a rebase, its entirely too easy to end up with kernel-2.6.21-*.config and kernel-2.6.22-*.config files laying about, which can sometimes cause odd things to happen), and we don't modify SOURCE files in %prep (see bug 232602), which could otherwise result in repacking an srpm with the same n-v-r with different kernel-*.config files. As a bonus, along the way, this cleans up a number of rpmlint warnings (though there are still a TON to poke at).
In the future, this would also make life easier for the RHEL6 and later maintainers, as we typically prefer config changes against the config-* files, rather than against the kernel-*.config files, but (most) non-rh folks don't have cvs access to get at the config-* files right now.
Thus far, the only real downside is that it requires moving all the config-* files up to the root of the kernel cvs dir, which is 1) a bit messy and 2) results in losing prior versioning history on those files, since cvs blows.
No big deal, though.
There's not much relevant history in there anyway.
My thoughts exactly.
(Hell, I'd even like to 'mv kernel-2.6.spec kernel.spec', but davej seems to not like that idea so much... ;)
Why?
I'm going to assume you're asking "why doesn't davej like that idea", since the mv desire is probably obvious (compliance w/packaging standards). Basically, because cvs sucks, and all revision history goes bye-bye if we do the move. Though really... Dave, how big a deal is that really if we do it this early in rawhide? You can always go to the attic if you *really* need to see some historical info on the spec, and we'll have plenty built back up by the time we get to F8...
On Thu, Jul 12, 2007 at 09:29:08AM -0400, Jarod Wilson wrote:
I'm going to assume you're asking "why doesn't davej like that idea", since the mv desire is probably obvious (compliance w/packaging standards). Basically, because cvs sucks, and all revision history goes bye-bye if we do the move. Though really... Dave, how big a deal is that really if we do it this early in rawhide? You can always go to the attic if you *really* need to see some historical info on the spec, and we'll have plenty built back up by the time we get to F8...
Probably not so big a deal if we do it right now I guess. It's been handy in the past for "it broke somewhere between 1.2345 and 1.2367", but tbh now that we have sensible versioning, that at least partially solves that probably without the need for cvs annotate.
Feel free to rename it, but be sure to fix up all the scripts/makefiles too.
Dave
On 07/12/2007 12:36 PM, Dave Jones wrote:
On Thu, Jul 12, 2007 at 09:29:08AM -0400, Jarod Wilson wrote:
I'm going to assume you're asking "why doesn't davej like that idea", since the mv desire is probably obvious (compliance w/packaging standards). Basically, because cvs sucks, and all revision history goes bye-bye if we do the move. Though really... Dave, how big a deal is that really if we do it this early in rawhide? You can always go to the attic if you *really* need to see some historical info on the spec, and we'll have plenty built back up by the time we get to F8...
Probably not so big a deal if we do it right now I guess. It's been handy in the past for "it broke somewhere between 1.2345 and 1.2367", but tbh now that we have sensible versioning, that at least partially solves that probably without the need for cvs annotate.
Feel free to rename it, but be sure to fix up all the scripts/makefiles too.
Maybe not such a good idea, since lots of external documentation refers to 'kernel-2.6.spec' as well.
On Thu, Jul 12, 2007 at 12:55:03PM -0400, Chuck Ebbert wrote:
On 07/12/2007 12:36 PM, Dave Jones wrote:
On Thu, Jul 12, 2007 at 09:29:08AM -0400, Jarod Wilson wrote:
I'm going to assume you're asking "why doesn't davej like that idea", since the mv desire is probably obvious (compliance w/packaging standards). Basically, because cvs sucks, and all revision history goes bye-bye if we do the move. Though really... Dave, how big a deal is that really if we do it this early in rawhide? You can always go to the attic if you *really* need to see some historical info on the spec, and we'll have plenty built back up by the time we get to F8...
Probably not so big a deal if we do it right now I guess. It's been handy in the past for "it broke somewhere between 1.2345 and 1.2367", but tbh now that we have sensible versioning, that at least partially solves that probably without the need for cvs annotate.
Feel free to rename it, but be sure to fix up all the scripts/makefiles too.
Maybe not such a good idea, since lots of external documentation refers to 'kernel-2.6.spec' as well.
Well, it'll catch up eventually. A lot of that documentation needs updating almost every time we do a release anyway for some reason or another.
Dave
Dave Jones wrote:
On Thu, Jul 12, 2007 at 12:55:03PM -0400, Chuck Ebbert wrote:
On 07/12/2007 12:36 PM, Dave Jones wrote:
On Thu, Jul 12, 2007 at 09:29:08AM -0400, Jarod Wilson wrote:
I'm going to assume you're asking "why doesn't davej like that idea", since the mv desire is probably obvious (compliance w/packaging standards). Basically, because cvs sucks, and all revision history goes bye-bye if we do the move. Though really... Dave, how big a deal is that really if we do it this early in rawhide? You can always go to the attic if you *really* need to see some historical info on the spec, and we'll have plenty built back up by the time we get to F8...
Probably not so big a deal if we do it right now I guess. It's been handy in the past for "it broke somewhere between 1.2345 and 1.2367", but tbh now that we have sensible versioning, that at least partially solves that probably without the need for cvs annotate.
Feel free to rename it, but be sure to fix up all the scripts/makefiles too.
Maybe not such a good idea, since lots of external documentation refers to 'kernel-2.6.spec' as well.
Well, it'll catch up eventually. A lot of that documentation needs updating almost every time we do a release anyway for some reason or another.
And just to be clear, I was only proposing this for rawhide, at least for the time being.
Chuck Ebbert wrote:
On 07/12/2007 12:36 PM, Dave Jones wrote:
On Thu, Jul 12, 2007 at 09:29:08AM -0400, Jarod Wilson wrote:
I'm going to assume you're asking "why doesn't davej like that idea", since the mv desire is probably obvious (compliance w/packaging standards). Basically, because cvs sucks, and all revision history goes bye-bye if we do the move. Though really... Dave, how big a deal is that really if we do it this early in rawhide? You can always go to the attic if you *really* need to see some historical info on the spec, and we'll have plenty built back up by the time we get to F8...
Probably not so big a deal if we do it right now I guess. It's been handy in the past for "it broke somewhere between 1.2345 and 1.2367", but tbh now that we have sensible versioning, that at least partially solves that probably without the need for cvs annotate.
Feel free to rename it, but be sure to fix up all the scripts/makefiles too.
Maybe not such a good idea, since lots of external documentation refers to 'kernel-2.6.spec' as well.
With luck, people will be bright enough to figure it out... :)
But we can do a possible spec name change separate from the proposed config changes. Speaking of which, they were just checked in (blame davej, he said 'do it').
kernel@lists.fedoraproject.org
-
Chuck Ebbert -
Dave Jones -
Jarod Wilson -
Josh Boyer