RFC feature/dep picking heuristics

[Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>]

On Wed, Jun 09, 2010 at 07:10:34PM +0200, Bernhard Reutner-Fischer wrote:
>Hi,
>
>These are independent.
>
>1) uClibc: redo configuration
>  improve configury of uClibc
[]
>3) busybox: picking IPv6 per default is not up to the package
>  first, busybox needs a better configury, like it's done for uclibc
>  in 1).
>  Second, who picks features and with what preference? packages? user?
>  distro? machine? See FIXME in 1).
>  This patchlet works around the real issue. Comments on how to tackle
>  the underlying issue (or how it's solved elsewhere if it already is,
>  i didn't see where/how ?) are _very_ welcome.

that FIXME in 1) reads:
index ee18fc8..b40fbf5 100644
--- a/conf/distro/include/uclibc.inc
+++ b/conf/distro/include/uclibc.inc
@@ -9,3 +9,11 @@ PREFERRED_PROVIDER_virtual/libintl_avr32 = "proxy-libintl"
 PREFERRED_PROVIDER_virtual/libc = "uclibc"
 PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-initial = "uclibc-initial"
 PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-for-gcc = "uclibc"
+
+# libc settings
+DISTRO_FEATURES += "${@['', '
+nls'][bb.data.getVar('ENABLE_BINARY_LOCALE_GENERATION', d, 1) == '1']}"
+MACHINE_FEATURES += "${@['', ' bx'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1)
+== 'thumb']}"
+# FIXME: We enable IPv4 per default to avoid alot of breakage.
+# FIXME: Figure out an acceptable way to negotiate either
+# FIXME: desired features or hard requirements, either top-down or bottom-up.
+DISTRO_FEATURES += " ipv4"


Problem description:

[all of the following is rather obvious, please accept my apologies for
being redundant and possibly not 100% accurate to keep this brief]

Two realms: Hardware / Software
Both of them provide optional features or impose hard constraints on the
setup.

I) hardware/kernel/libc
  Think arm thumb interworking bx or not any or all of them.
    libc can use BX or fallback but only for thumb and for some
    -mtune's (IIRC).
  networking.
    - none
    - socket
    - ipv4 (requires socket)
    - ipv6 (requires socket)
    - ipv4 || ipv6
  nls.
    - locales to generate (GLIBC_GENERATE_LOCALES; uclibc can use the same)
    - several other options, namely wchar (think mc or mutt -- if forgot
      which one -- which requires wchar if not patched)

II) packages
  consider micro-base-image for libc=uclibc
  consider recipes are equipped with HANDLE_FEATURE (big TODO, RFC).
  assume HANDLE_FEATURE is auto-filled off configure.ac for the most
    part.
  that one selects sysvinit (bug per se but no relevant for now)
  sysvinit uses inet_ntoa() or something to that effect
    unconditionally -> not buildable since not base_contains HANDLE_FEATURE ipv4

Now my question is:
How can i fit a set of requirements to a set of config options that make
up a system (ideally without changing anything)?

If i have to change something, how should the decision-flow look like to
weight constraints against possibly provided features? What's the
precedence of the following parts:
o HW hard constraints
o HW soft constraints (optional features)
o kernel/Lowlevel hard constraints
o kernel/Lowlevel soft constraints (optional features)
o libc hard constraints (unconfigurable vs. configurable)
o libc soft constraints (optional features)
o package hard constraints (sysvinit requires ipv4)
o package soft constraints (optional features, like iptables/busybox ipv6)

TIA for clarifications or pointers to existing docs covering OE in this
respect && cheers,