Re: Background to the argument about CML2 design philosophy

[John Stoffel <stoffel@casc.com>]

David> Actually, the current system has both types. As well as the
David> "hard" dependencies, we also have stuff like
David> CONFIG_PARTITION_ADVANCED, CONFIG_CPU_ADVANCED,
David> CONFIG_FBCON_ADVANCED, CONFIG_MTD_DOCPROBE_ADVANCED,
David> etc. CONFIG_EXPERIMENTAL serves a very similar purpose, too.

David> These things have already been set up in the way that
David> developers prefer it.

     *some* developers prefer it.  Not all. 

David> CML2 allows us to be more flexible than we were before, and
David> that can be a good thing when used in moderation. But please,
David> for the sake of the sanity of all concerned, do things one at a
David> time. Provide for merging into 2.5 a set of rules which
David> reproduce the existing CML1 behaviour in this respect.

Can you define what you mean here?  It's not really clear to me, and I
suspect others.  

David> Eric, if you want to make further changes later to introduce
David> new 'modes' for kernel configuration, that's an entirely
David> separate issue. Please don't confuse the issue by trying to do
David> it at the same time as introducing CML2.

I don't think he is introducing new modes, he's just trying to make
sure that you can't create a .config which is broken.  Part of my
complaint early on was that it would just barf on a config it thought
wasn't legall, and just drop me to the 'vi' level.  I don't think this
is acceptable because you (CML2 or CMLxxxx) should be able to prompt
the user for a suggested fix.  

David> CONFIG_AUNT_TILLIE does not require CML2.

Correct.

David> CML2 does not require CONFIG_AUNT_TILLIE.

Correct.  And never has offered it either!

David> Let's not talk about CONFIG_AUNT_TILLIE any more, or change the
David> existing behaviour of config options to make that the default,
David> until we've settled the discussion about CML2.

I think it comes down to people who just want one or more of:

- the existing interface of vi .config; make oldconfig

- fear that CML2 won't let them make crazy configurations, such as an
  8-way SMP box with ISA.  Can't see how CML2 would restrict this
  choice myself.

- Don't want to install python 2.x for a kernel upgrade.

- fear that some configuration corner case will be handled wrong for a
  strange (read not common) system config.  


All that CML2 does is enforce dependencies in the configuration
language.  You can't make a .config which conflicts.  Admittedly
there's nothing stopping you from hacking it with vi after the fact,
but why?

If you run into a case where you have a config which would work, but
CML2 doesn't let you, why don't you fix the grammar instead of saying
CML2 is wrong?  Let's not confuse these two issues as well.

John