Fedora kernel list - Jul 2007 - [RFC PATCH] Switch to including config-* instead of kernel-*.config

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!

-- 
Jarod Wilson
jwilson@redhat.com

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.
>>
> 
> 1) No big deal, though.
> 
> 2) 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... ;)

-- 
Jarod Wilson
jwilson@redhat.com

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.
> >>
> > 
> > 1) No big deal, though.
> > 
> > 2) 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.
>>>>
>>> 1) No big deal, though.
>>>
>>> 2) 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...

-- 
Jarod Wilson
jwilson@redhat.com

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

-- 
http://www.codemonkey.org.uk

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

-- 
http://www.codemonkey.org.uk

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'').

-- 
Jarod Wilson
jwilson@redhat.com

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.

-- 
Jarod Wilson
jwilson@redhat.com