On 5/16/07, Satyam Sharma <[email protected]> wrote:
On 5/16/07, Al Viro <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
