[oe] [RFC] ANGSTROM_MODE -> SYSTYPE

[Paul Sokolovsky]

Hello Rod,

Sunday, December 16, 2007, 6:51:51 AM, you wrote:

> Paul Sokolovsky wrote:
>>   Well, SYSTYPE has another aim and idea in its introduction. I hinted
>> about that in original mail, now let me make it explicit: the proposal
>> is about introduction of the standard OE variable name for distro
>> parameter tweaking. Its meaning however completely depends on the
>> distro. Some distro needs switch libc's. Some needs to switch WMs.
>> Others need to switch many other things, possibly, in combinations.
>> Very good. OE recommends a standard general syntax for that - a
>> SYSTYPE. Exact format of what goes into SYSTYPE and its semantics is
>> up to distro (and users will know about all that by reading distro's
>> docs). (Now that we talk about validation, it puts additional
>> syntactic constraints on SYSTYPE value, that's why I'm personally not
>> keen to start with [rigid] validation from the beginning).

> How is this different to the USE flags proposals that have come and gone
> in the past?

  At least in naming. Because whenever word "USE" appears in
discussion, someone comes to explain hardnesses of QAing a system,
packages of which are being built using different compile-time
settings.

  At the same time, OE already uses generalized USE conception a lot:
DISTRO_FEATURES, MACHINE_FEATURES - are all those generalized USE
flags, just working not on the package configuration level (like some
other systems allow, and we don't want), but on distro configuration
level. But DISTRO_FEATURES & MACHINE_FEATURES are "blackbox"
parameters, intended for developers. You can't drop "wifi" from
Angstrom's DISTRO_FEATURES and still call/think that it is Angstrom.
On the other hand, SYSTYPE is intended as a whitebox parameter,
together with the other 2 - DISTRO & MACHINE providing the well-known
and complete set of knobs allowing *user* to build a legitimate distro
image adjusted to user's need, and within the bounds allowed by a
distro.

> -- Rod



-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com