Date:	Wed, 16 May 2007 21:01:32 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Al Viro" <viro@....linux.org.uk>, linux-kernel@...r.kernel.org,
	zippel@...ux-m68k.org, kbuild-devel@...ts.sourceforge.net,
	"Stefan Richter" <stefanr@...6.in-berlin.de>
Subject: Re: [RFC] select and dependencies in Kconfig

On 5/16/07, Satyam Sharma <satyam.sharma@...il.com> wrote:
> On 5/16/07, Al Viro <viro@....linux.org.uk> wrote:
> > On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
> > >
> > > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
> > > end up with unbuildable configs.
> >
> > BTW, this kind of situation happens often enough, so how about doing
> > the following: teach kconfig that if FOO selects BAR and BAR depends
> > on <expr>, we should act as if FOO had explicit depends on <expr>.
> >
> > Rationale: if FOO selects BAR, BAR depends on <expr> and <expr> is false,
> > turning FOO on will land us into unbuildable configuration (BAR turned on,
> > dependencies of BAR are not satisfied).  It really happens often enough to
> > be very annoying.  And we have fsckloads of dependencies that are there
> > only because of such scenarios.  Gets especially nasty when BAR is selected
> > by several dozens of options and dependencies of BAR change...
>
> [ First off, "select"ing BAR that itself "depends on" BAZ is evil and
> should be avoided, except where BAR is strictly library-like and thus
> has simple or few basic dependencies. Still, like you say, dependencies
> of BAR can change over time, or one could want to be lazy and wish to
> avoid burdening users with having to pick dependencies _before_ the
> option they're interested in -- especially with menuconfig not even
> showing options whose dependencies are not satisfied already. ]
>
> Anyway, I'd gotten into a couple of threads discussing precisely this over
> the last couple of weeks, and thought of more-or-less a similar solution:
> http://lkml.org/lkml/2007/5/7/332
>
> When user picks FOO, we select BAR and note its dependencies (i.e. BAZ).
> Build a complete dependency tree (FOO upwards), and show to the user all
> the other config options (such as BAZ) that will now have to be picked
> to satisfy user's selection of FOO without causing build breakages. If
> user says yes, we *select* BAZ too (so now it can't be un-selected). If
> user says no, FOO is not picked at all.
>
> On 5/16/07, Al Viro <viro@....linux.org.uk> wrote:
> > Implementing that is pretty simply; the only thing I'm not sure how to deal
> > with is how to show such inherited dependencies in menuconfig et.al.
>
> On 5/16/07, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> > Sounds sane. I wonder if there are any non-obvious gotchas, and I worry
> > that the indirect dependency ends up getting really confusing at times,
> > but I don't think the notion is broken - just worrying about how to *show*
> > this to explain what is going on when people say "why can't I select X".
>
> For menuconfig / xconfig it _could_ simply be another dialog box that
> pops up the moment user picks FOO.
>
> For config/oldconfig/etc non-curses/graphics-based ones, we could do
> something like what "yum" does for package dependencies on Red Hat
> and Fedora. Once the entire thing is done, just run through the entire
> .config just generated, and build these complete dependency trees for
> all picked options, and thus compiling a list of all the BAZ'es that also
> need to be picked now to satisfy user's demand for the FOO's.
> Simple Y/n then follows.

One minor glitch here: BAZ may not be a "select"able dependency at all.
Like Al wrote, it could be an <expr> that is something like !SMP etc that
can't be meaningfully selected.
For that case, menuconfig / xconfig could simply show up a dialog
explaining why the user's selection of FOO can't be allowed, and
config/oldconfig/etc can simply refuse to write out the broken .config.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists