Message-ID: <a781481a0705160720p58f0730ehcb491bb6e111f924@mail.gmail.com>
Date:	Wed, 16 May 2007 19:50:05 +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
Subject: Re: [RFC] select and dependencies in Kconfig

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.

Satyam
-
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