On 01/06/2011 12:45 PM, Jarod Wilson wrote:
On Thu, Jan 06, 2011 at 12:33:40PM -0800, JD wrote:
> On 01/06/2011 07:18 AM, Jarod Wilson wrote:
>> On Thu, Jan 06, 2011 at 12:15:51AM -0500, Don Zickus wrote:
>>> On Wed, Jan 05, 2011 at 11:47:41PM -0500, Jarod Wilson wrote:
>>>>> So, what do I do? I simply prep from source
>>>>> (rpmbuild -bp kernel.spec)
>>>>> and then cd to
~/rpmbuild/BUILD/kernel-2.6.35.10-74/linux-2.6.35.i686,
>>>>> copy my current kernel's config file to .config, run
>>>>> make oldconfig and
>>>>> male all
>>>>> and that does it.
>>>>> The new config file inherits my enabled drivers selections.
>>>>> From the kernel spec:
>>>> # Dynamically generate kernel .config files from config-* files
>>>> make -f %{SOURCE20} VERSION=%{version} configs
>>>>
>>>> And Source20 is Makefile.config, from which with a bit of effort, you
can
>>>> determine the order in which the various config-* files are smashed
>>>> together to form the end result .config files.
>>>>
>>>> I think this topic actually came up once in the past, and an idea to add
>>>> an extra layer similar to the 'if rhel' clause in the spec was
kicked
>>>> around, but never came to fruition. In theory, that file would, if
>>>> present, apply additional Kconfig changes from an additional overrides
>>>> file. It could be an empty file by default, but obviously named or
>>>> documented, so that anyone rebuilding could simply put their assorted
>>>> additional config options in there, and they'd always be applied over
the
>>>> top of the stock config options.
>>> Ha! I can't believe the rhel stuff I added is still there.
>> I dunno if it got used for RHEL6 initially or not... I'd be inclined to
>> rip it out, and we can add something similar back next time we've got
>> another RHEL major release on the horizon... Maybe that gives away too
>> many secrets though. :)
>>
>>> We could probably mimic the old linux-kernel-test.patch which was a stub
>>> patch to allow developers to quickly test their patches without mucking
>>> with the spec file, but instead for config files (like the %rhel thing).
>> I think this would suffice:
>>
>> # This file is empty in stock builds, but can be populated with local
>> # config option overrides for custom local builds
>> Source1000: config-local
>>
>>
>> Then, in %prep, in a loop similar to the if rhel one:
>>
>> ./merge.pl %{SOURCE1000} $i.tmp> $i
>>
>>
>> Since the file is empty in stock configs, the above in that case would
>> simply be a no-op. If its populated by someone doing a local rebuild, then
>> their config options get overlayed on top of the stock ones.
>>
> Hi Jarod,
> Do you even need the for loop? Since you are dealing with just one
> local config file?
> Or is the purpose of putting it in the loop to superimpose the
> local configs on top
> of the vanilla configs for all the kernel.*-config files?
Yes, the idea is to overlay the changes on every flavor of kernel. In the
standard released kernel rpmbuild for x86_64, you get kernel and
kernel-debug, and we want the changes stacked on top of both of them. The
for loop also makes sure its arch-agnostic.
OK, I understand.
Would this loop in the spec file do it?
.
.
for i in %{all_arch_configs}
do
mv $i $i.tmp
./merge.pl %{Source1000} $i.tmp > $i
rm $i.tmp
done
Thanx,
JD