Public SourceMage Discussion List

["Sergey A. Lipnevich" <sergey AT optimaltec.com>]

Quoting "David Michael Leo Brown Jr." <dmlb2000 AT excite.com>:

> Ooopsie didn't read that quite right... the yes "" | would make 
> oldconfig accept
> the defaults for any options that aren't present in the config file...
>
> But I still don't like cutting the user out of creating the config file

If there's an existing config, that seems to be your only option to allow the
spell co build successfully.

I can't do this experiment right now, but what would happen if I installed
2.6.10 kernel using linux-new, and then kept using it until 2.6.11 came out?
New parameters are guaranteed to emerge between these two major releases, so
without doing "make oldconfig" or "make menuconfig" the kernel woudn't build.
Do we agree on this last statement or I am misstating something? If we agree,
than would my only option to make linux-new build again be "cast -r" or I have
any other choices?

With current spell, I can lazily choose "run oldconfig" and use the same
features I used in 2.6.10. If I need new features I would still not use "cast
-r" (I never do it with current linux spell), because it would forget what
branch of kernel I prefer (I may not remember which one I selected for a
particular machine, so this is important, especially in production). I 
would do
"cast linux" and say "yes" to "configure linux kernel" question. I would leave
the kernel branch intact, and wait until menuconfig shows up. While 
this is not
intuitive, it covers most scenarios for kernel upgrade, and works reliably.

I admit that I am not a power user of the linux spell, I almost never use any
patches, always stock kernel source (it may be rc or mm or something else, but
I consider this "stock" code too). Does this mean that linux-new spell is not
for me?

Sergey.