Skip to content

Introduce the _AVAILABLE mechanism

Thomas Petazzoni buildroot 1 version New

Get series with b4
b4 am 20121014193849.019347dd@skate

Versions newest first

  1. v1 Latest0 of 7 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 7 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

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

Yann,

Quoted 5 lines · Yann E. MORIN
Quoted 3 lines

Looking at the first one, it seems to be caused by the fact that all Python external packages are enclosed inside a "if BR2_PACKAGE_PYTHON" in package/Config.in, so this Python dependency is already available.

Strange. I do not recall all those recursive deps issues. I'll check here.

Ok.

Quoted 2 lines

My gut feeling is that the "if BR2_PACKAGE_PYTHON" should go, now that we have _AVAILABLE.

Yes, it's a possible solution that sounds reasonable.

Quoted 25 lines
Quoted 9 lines

But then in that case, we should also have a BR2_PACKAGE_PYTHON_ZLIB_AVAILABLE symbol, so that python-dpkt can depend on it instead of forcefully selecting BR2_PACKAGE_PYTHON_ZLIB, without knowing if zlib is available or not.

This problem however is going to be present in many many places, so I don't know if manual intervention is reasonable for it. But on the other hand, I am not sure it is possible to write an automated script to solve this problem.

As much as I remember, there were not so much cases like that. But, except for manual intervention, I do not see how we could differentiate that case.

The problem is (form my script's point of view):
Is BR2_PACKAGE_PYTHON_ZLIB representing:
- the package "python-zlib", or
- the option "zlib" of the package "python"?

Except for intrumenting the option symbol (eg.: BR2_PACKAGE_PYTHON_OPT_ZLIB) which I doubt we want to, there is no easy way for the script to detect this situation.

And then, do we want to push the _AVAILABLE semantic dow to sub-option? I doubt we do.

Quoted 6 lines

So, depending on sub-options should be as:

config BR2_PACKAGE_PYTHON_DPKT_AVAILABLE
def_bool y
depends on BR2_PACKAGE_PYTHON_AVAILABLE depends on BR2_PACKAGE_PYTHON_ZLIB # Sub-option

Unfortunately this is not what we want:

* We want the python-dpkt package to be visible to the user only if Python (BR2_PACKAGE_PYTHON) has been enabled;

* However, when one enables BR2_PACKAGE_PYTHON, we want the python-dpkt package to be visible even if the BR2_PACKAGE_PYTHON_ZLIB option is not selected, and we want this option to be automatically enabled when the user enables the python-dpkt package. However, we have to be careful not to show the python-dpkt option if for some reason the BR2_PACKAGE_PYTHON_ZLIB option cannot be selected due to a dependency that isn't available (in our zlib is available on all architectures, but we could imagine depending on, say, libfoobar that is only available on certain architectures)

The reasoning is that:

* We can assume that a user knows that the Python interpreter should be enabled in order to see all Python external packages;

* However, we don't want to have the user to know about the need to enable the BR2_PACKAGE_PYTHON_ZLIB suboption in order to get access to python-dpkt.

In other words: we can assume the user knows about big subsystems (X.org, Python, Perl, etc.), but we don't want him to know the fine details of the dependencies on sub-options.

Quoted 6 lines
Quoted 3 lines

Here, I don't think an automated process is possible, a human intervention will be needed to find out if those legacy dependencies can be removed or not, on a case by case basis.

Yep, manual intervention, one of the corener-cases I wrote about in my intro mail.

Ok.

Quoted 5 lines
Quoted 2 lines

So all in all, the problem I'm most worried about is problem (2). Have you thought about it already?

Yep, I've thought about it. Answer: manual review.
( Don't worry, *I* will have to do it before I submit a final series! ;-) )

Ok.

So, for me, problem (2) remains unsolved at the moment. I guess the only solution is to add _AVAILABLE kconfig knobs for all the package sub-options that select other packages. But this means adding a lot more _AVAILABLE knobs than we initially thought.

Thomas

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

Read the cover letter in its thread