[Buildroot] [PATCH 0/7] Introduce the _AVAILABLE mechanism

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

Yann,

On Wed, 17 Oct 2012 22:16:43 +0200, Yann E. MORIN wrote:

> > From a quick review, it sounds sufficient indeed. What surprises me
> > is why we didn't think about this solution the other day when
> > discussing your _AVAILABLE patch set.
> 
> To be honest, I'm surprised too I did not think about it. ;-]
> 
> In fact, as an after-thought, I do know why. That's because I was
> thinking the other way-around: a package that depends on a sub-option
> of another package, sub-option which in turn depends on a third
> package.  *That* one would require an _AVAILABLE for sub-options.

Aaah yes.

> For example, libuuid which is a sub-option of util-linux (although
> that one sub-option has no dpendency; but you get the idea) is select
> by a few other packages (eg. parted, ntfs-3g...).
> 
> And going *that* route is IMHO not what we want.

Our example was the one of python-dpkt, which was doing a:

	depends on BR2_PACKAGE_PYTHON
	select BR2_PACKAGE_PYTHON_ZLIB

or BR2_PACKAGE_PYTHON_ZLIB is not a package per-se, but a sub-option of
the python package. And this this sub-option does a select, we should
introduce a BR2_PACKAGE_PYTHON_ZLIB_AVAILABLE, I don't see a way around
it.

Except modifying kconfig, as we discussed, of course...

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com