Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

[Matt Mackall]

On Mon, Feb 05, 2007 at 08:09:58PM -0500, Theodore Tso wrote:
> On Mon, Feb 05, 2007 at 11:21:34PM +0000, David Woodhouse wrote:
> > But Alan makes a reasonable suggestion -- we could work around this in
> > the tools too. 
> 
> I wouldn't call it "work around this" in the tools.  It's a useful
> feature we can add in the tools for developers who aren't men enough
> to use "sed/grep" pipelines.  :-)
> 
> But I have to agree with Linus here that we should be optimizing the
> tools for people who know how to compile the kernel, but who aren't
> necessarily familiar with all of the hidden dependencies in the
> literally hundreds of config options in the kernel tree.  In reality,
> you want to make it easy to turn on *or* off any arbitrary config
> option, and to understand what you need to do so you can turn an
> arbitrary config option on or off.  If that means tools enhancements,
> so be it.  

With apt (or presumably with yum), you can happily apt-remove
a package that nothing else depends on. If you remove something that
other things depend on, you get a list of those things and opportunity
to force it (with a -f flag, for instance). If you ask for a package
that has other dependencies, it automatically pulls all those things
in unless there's a conflict. In which case you can force it again.

There's no reason we shouldn't be able to do exactly that with config
symbols in Kconfig-land. The only difference is that we've got
slightly different semantics for our "depend" keyword. Things which
don't have their "depend" requirements met aren't offered as options.
Whereas "select" is "automatically pull in dependencies"
apt/yum-style.

While we're at it, it would also be nice to be able to do:

$ kconfig enable ACPI
CONFIG_ACPI conflicts with CONFIG_APM
$ kconfig enable -F ACPI
disabling CONFIG_APM
$ kconfig disable SCSI
CONFIG_USB_STORAGE depends on CONFIG_SCSI
$ kconfig disable -f SCSI
disabling USB_STORAGE
$ make

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/