[RFC] ANGSTROM_MODE -> SYSTYPE

[RFC] ANGSTROM_MODE -> SYSTYPE

[Paul Sokolovsky]

Hello Openembedded-devel,

   ANGSTROM_MODE config variable has proven to be very useful and
successful feature during the Angstrom evolution. IMHO, it is worth
generalization of its meaning and naming to become a generic
additional OE distro configuration parameter. So, I'd like to propose
it to be renamed to SYSTYPE, with the description "Select particular
system variant of a distribution which supports such feature, e.g.,
underlying libc type."

  Obviously, it wouldn't be limited to libc type, but intended to be a
generic sub-parameter of a distro, it could be debug/release type,
size type (minimal/standard/extended), whatever. The usage idea is to
have standard name for such generic parameter, plus semantically it
should be expected that a distro allows to build different SYSTYPE's
side-by-side in the same build dir (like Angstrom does for libc
variants).


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

Re: [RFC] ANGSTROM_MODE -> SYSTYPE

[Khem Raj]

I agree we should make it global.

On Dec 14, 2007 6:39 PM, Paul Sokolovsky <pmiscml@gmail.com> wrote:
> Hello Openembedded-devel,
>
>    ANGSTROM_MODE config variable has proven to be very useful and
> successful feature during the Angstrom evolution. IMHO, it is worth
> generalization of its meaning and naming to become a generic
> additional OE distro configuration parameter. So, I'd like to propose
> it to be renamed to SYSTYPE, with the description "Select particular
> system variant of a distribution which supports such feature, e.g.,
> underlying libc type."
>
>   Obviously, it wouldn't be limited to libc type, but intended to be a
> generic sub-parameter of a distro, it could be debug/release type,
> size type (minimal/standard/extended), whatever. The usage idea is to
> have standard name for such generic parameter, plus semantically it
> should be expected that a distro allows to build different SYSTYPE's
> side-by-side in the same build dir (like Angstrom does for libc
> variants).
>
>
> --
> Best regards,
>  Paul                          mailto:pmiscml@gmail.com
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] ANGSTROM_MODE -> SYSTYPE

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Sokolovsky schreef:
> Hello Openembedded-devel,
> 
>    ANGSTROM_MODE config variable has proven to be very useful and
> successful feature during the Angstrom evolution. IMHO, it is worth
> generalization of its meaning and naming to become a generic
> additional OE distro configuration parameter. 
> So, I'd like to propose
> it to be renamed to SYSTYPE, with the description "Select particular
> system variant of a distribution which supports such feature, e.g.,
> underlying libc type."

How will a user know if that flag is supported for the distro he/she
wants to use?
should we enhance insane.bbclass to crosscheck TARGET_OS with
SYSTYPE_FOO for the uclibc vs glibc case? And if so, how would it check
between glibc and eglibc?
Having an *easier* OE-blessed way for switching C library would be nice,
but let's make sure people don't shoot themselves in the foot by setting
SYSTYPE_FOO with a distro that has no knowledge of it.

regards,

Koen


>   Obviously, it wouldn't be limited to libc type, but intended to be a
> generic sub-parameter of a distro, it could be debug/release type,
> size type (minimal/standard/extended), whatever. The usage idea is to
> have standard name for such generic parameter, plus semantically it
> should be expected that a distro allows to build different SYSTYPE's
> side-by-side in the same build dir (like Angstrom does for libc
> variants).
> 
> 


- --
koen@dominion.kabel.utwente.nl will go go away in december 2007, please
use k.kooi@student.utwente.nl instead.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHY7EoMkyGM64RGpERAh1uAJ9/QUGnhZ+4/zKUeOZSgIgMNyuwUACfYb3a
gy3s4p4svQ8M8rbFxThH+9I=
=3c7/
-----END PGP SIGNATURE-----

Re: [RFC] ANGSTROM_MODE -> SYSTYPE

[Paul Sokolovsky]

Hello Koen,

Saturday, December 15, 2007, 12:49:12 PM, you wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> Paul Sokolovsky schreef:
>> Hello Openembedded-devel,
>> 
>>    ANGSTROM_MODE config variable has proven to be very useful and
>> successful feature during the Angstrom evolution. IMHO, it is worth
>> generalization of its meaning and naming to become a generic
>> additional OE distro configuration parameter. 
>> So, I'd like to propose
>> it to be renamed to SYSTYPE, with the description "Select particular
>> system variant of a distribution which supports such feature, e.g.,
>> underlying libc type."

> How will a user know if that flag is supported for the distro he/she
> wants to use?

  How user knows which distros are available in the first place? She
goes and looks up them in configs or reads documentation. How user
knows which SYSTYPEs are supported, if any, for some distro? She does
the same regarding configs/docs reading.

> should we enhance insane.bbclass to crosscheck TARGET_OS with
> SYSTYPE_FOO for the uclibc vs glibc case? And if so, how would it check
> between glibc and eglibc?

  User "input" validation is always a nice thing, but adds a bunch of
code, and OE lacks it many places anyway ;-). Well, we could solve it
in this case like this for example: Make supporting distro set
SYSTYPES_AVAILABLE, and make insane.bbclass (or maybe even
sanity.bbclass) to check that SYSTYPE value appears there.

> Having an *easier* OE-blessed way for switching C library would be nice,
> but let's make sure people don't shoot themselves in the foot by setting
> SYSTYPE_FOO with a distro that has no knowledge of it.

  Switching C library in merely a particular use case of ability to
adjust an important distro parameter without formally creating another
distro [config or build area]. So useful for Angstrom, it is useless
for some deeply-embedded distro which is developed and QA solely
against uclibc. Such a distro can use SYSTYPE for some other important
parameter they want to tweak. More on this in another mail.

> regards,

> Koen


>>   Obviously, it wouldn't be limited to libc type, but intended to be a
>> generic sub-parameter of a distro, it could be debug/release type,
>> size type (minimal/standard/extended), whatever. The usage idea is to
>> have standard name for such generic parameter, plus semantically it
>> should be expected that a distro allows to build different SYSTYPE's
>> side-by-side in the same build dir (like Angstrom does for libc
>> variants).
>> 
>> 





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

Re: [RFC] ANGSTROM_MODE -> SYSTYPE

[Leon Woestenberg]

Hello all,

On Dec 15, 2007 3:39 AM, Paul Sokolovsky <pmiscml@gmail.com> wrote:
>    ANGSTROM_MODE config variable has proven to be very useful and
> successful feature during the Angstrom evolution. IMHO, it is worth
> generalization of its meaning and naming to become a generic
> additional OE distro configuration parameter. So, I'd like to propose
> it to be renamed to SYSTYPE, with the description "Select particular
> system variant of a distribution which supports such feature, e.g.,
> underlying libc type."
>
NAK on the name and the combination with other settings:

>   Obviously, it wouldn't be limited to libc type, but intended to be a
> generic sub-parameter of a distro, it could be debug/release type,
> size type (minimal/standard/extended), whatever. The usage idea is to
>
C library selection is mostly orthogonal from the
debug/profile/test/release/whatever type.
Also, C library selection is mostly orthogonal from the size type (in
fact, that's a target, not
a property of it).

> have standard name for such generic parameter, plus semantically it
> should be expected that a distro allows to build different SYSTYPE's
> side-by-side in the same build dir (like Angstrom does for libc
> variants).
>
*If* you want to go for this, I would propose DISTRO_LIBC instead and
NOT mix this with any other settings, which are orthogonal and mostly
unrelated.

(I.e. the fact that I want to profile my image, is independent on
whether I built with eglibc or glibc).

Also, I agree with Koen that we then end up in the situation where
people may assume this flag is always respected, while it's dependent
on the distro.

-1 for the proposal

+0 for the making DISTRO_LIBC a global C library selector.

Regards,
-- 
Leon

Re: [RFC] ANGSTROM_MODE -> SYSTYPE

[Paul Sokolovsky]

Hello Leon,

Saturday, December 15, 2007, 3:26:40 PM, you wrote:

> Hello all,

> On Dec 15, 2007 3:39 AM, Paul Sokolovsky <pmiscml@gmail.com> wrote:
>>    ANGSTROM_MODE config variable has proven to be very useful and
>> successful feature during the Angstrom evolution. IMHO, it is worth
>> generalization of its meaning and naming to become a generic
>> additional OE distro configuration parameter. So, I'd like to propose
>> it to be renamed to SYSTYPE, with the description "Select particular
>> system variant of a distribution which supports such feature, e.g.,
>> underlying libc type."
>>
> NAK on the name and the combination with other settings:

>>   Obviously, it wouldn't be limited to libc type, but intended to be a
>> generic sub-parameter of a distro, it could be debug/release type,
>> size type (minimal/standard/extended), whatever. The usage idea is to
>>
> C library selection is mostly orthogonal from the
> debug/profile/test/release/whatever type.
> Also, C library selection is mostly orthogonal from the size type (in
> fact, that's a target, not
> a property of it).

  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).

>> have standard name for such generic parameter, plus semantically it
>> should be expected that a distro allows to build different SYSTYPE's
>> side-by-side in the same build dir (like Angstrom does for libc
>> variants).
>>
> *If* you want to go for this, I would propose DISTRO_LIBC instead and
> NOT mix this with any other settings, which are orthogonal and mostly
> unrelated.

> (I.e. the fact that I want to profile my image, is independent on
> whether I built with eglibc or glibc).

> Also, I agree with Koen that we then end up in the situation where
> people may assume this flag is always respected, while it's dependent
> on the distro.

> -1 for the proposal

  Please rethink.

> +0 for the making DISTRO_LIBC a global C library selector.

  Gotcha! That's exactly what I'm trying to avoid - proliferation of
adhoc distro config parameters! We have ANGSTROM_MODE now, supposedly
FooNas will want to call it FOONAS_LIBC, with lots others alike. Then
lots of others will introduce lots of others config parameter, making
OE maintainers and users screem. No, let's think it out now, acting on
numerous complaints that OE is too complex to setup (which includes
configuration) by mere humans. How it was before, there're two
parameters had to be set to build a proper package/image: DISTRO and
MACHINE. As we all hopefully agree that tweaking high-level distro
settings without formally introducing a new distro is a nice thing,
let's add one another parameter to this, and let users and developers
know that it is the recommended way to do it. So, a user could build a
package/image using:

DISTRO=<distro> SYSTYPE=<systype> MACHINE=<machine> bitbake <package>

   In ideal world (and we'll get there, I trust), this will be possible
after OE checkout, without adding any weird configs with weird
settings users can't get. Then, we'll even address rights of
environment-use-challenged users, by adding corresponding options to
bitbake itself:

bitbake --distro=foo --systype=bar --machine=baz package

  And nothing really precludes SYSTYPE to be not just "libc", but
"libc,release", or "libc,release,wm=xfce", or
"libc,release,wm=xfce,weird_user_config=some_file.conf".

> Regards,



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

Re: [RFC] ANGSTROM_MODE -> SYSTYPE

[Rod Whitby]

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?

-- Rod

Re: [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@gmail.com

Re: [RFC] ANGSTROM_MODE -> SYSTYPE

[Leon Woestenberg]

Hello Paul,

> ...the proposal
> is about introduction of the standard OE variable name for distro
> parameter tweaking. Its meaning however completely depends on the
> distro.
>
Do you see the contradiction? A *standard* OE variable name that
*completely depends* on the
distro. Please, no.

> 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).
>
MACHINE and DISTRO are extremely well understood: they select one
option out of a list, and the name implies what you select.

Extremely user friendly.

SYSTYPE does not fulfill these two properties in your proposal.

> > +0 for the making DISTRO_LIBC a global C library selector.
>
>   Gotcha! That's exactly what I'm trying to avoid - proliferation of
> adhoc distro config parameters! We have ANGSTROM_MODE now, supposedly
> FooNas will want to call it FOONAS_LIBC, with lots others alike. Then
>
No, "DISTRO_LIBC". Literally. Like Marcin set out more explicitly than I did.
> bitbake --distro=foo --systype=bar --machine=baz package
>
Argh. No!

>   And nothing really precludes SYSTYPE to be not just "libc", but
> "libc,release", or "libc,release,wm=xfce", or
> "libc,release,wm=xfce,weird_user_config=some_file.conf".
>
Sorry, you didn't convince me, at all.

I strongly agree with Richard to either not do this (therefore my -2),
or either to define a sane namespace that some distro's might support,
agreeing with Marcin.

Regards,
-- 
Leon

Re: [RFC] ANGSTROM_MODE -> SYSTYPE

[Paul Sokolovsky]

Hello Leon,

Thursday, December 20, 2007, 8:38:12 PM, you wrote:

> Hello Paul,

>> ...the proposal
>> is about introduction of the standard OE variable name for distro
>> parameter tweaking. Its meaning however completely depends on the
>> distro.
>>
> Do you see the contradiction? A *standard* OE variable name that
> *completely depends* on the
> distro. Please, no.

  Well, it seems you mix up *levels*. The variable with standard
*name*, whose *value* gets interpreted by a distro, what's a problem
here? You know, it's like PATH unix envvar - it is standard,
but different systems and different users put different stuff there.

>> 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).
>>
> MACHINE and DISTRO are extremely well understood: they select one
> option out of a list, and the name implies what you select.

> Extremely user friendly.

> SYSTYPE does not fulfill these two properties in your proposal.

 ??? How it is not? Do you have a proposal for better name?

>> > +0 for the making DISTRO_LIBC a global C library selector.
>>
>>   Gotcha! That's exactly what I'm trying to avoid - proliferation of
>> adhoc distro config parameters! We have ANGSTROM_MODE now, supposedly
>> FooNas will want to call it FOONAS_LIBC, with lots others alike. Then
>>
> No, "DISTRO_LIBC". Literally. Like Marcin set out more explicitly than I did.
>> bitbake --distro=foo --systype=bar --machine=baz package
>>
> Argh. No!

  Indeed? Maybe you even have arguments? ;-) Or rather, maybe you have
the whole paradigm how make OE more friendly for newcomers/casual
users? Please share, that's what I'm trying to solve here.

>>   And nothing really precludes SYSTYPE to be not just "libc", but
>> "libc,release", or "libc,release,wm=xfce", or
>> "libc,release,wm=xfce,weird_user_config=some_file.conf".
>>
> Sorry, you didn't convince me, at all.

> I strongly agree with Richard to either not do this (therefore my -2),
> or either to define a sane namespace that some distro's might support,
> agreeing with Marcin.

  We somehow interpret differently what Richard wrote. Per my
understanding, his concern was that it won't be clear if given feature
will be supported by some distro, or no. SYSTYPE offers validation to
solve this issue.

> Regards,



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

Re: [RFC] ANGSTROM_MODE -> SYSTYPE

[Leon Woestenberg]

Hello Paul,

On Dec 20, 2007 9:10 PM, Paul Sokolovsky <pmiscml@gmail.com> wrote:
> Thursday, December 20, 2007, 8:38:12 PM, you wrote:
> >> ...the proposal
> >> is about introduction of the standard OE variable name for distro
> >> parameter tweaking. Its meaning however completely depends on the
> >> distro.
> >>
> > Do you see the contradiction? A *standard* OE variable name that
> > *completely depends* on the
> > distro. Please, no.
>
>   Well, it seems you mix up *levels*. The variable with standard
> *name*, whose *value* gets interpreted by a distro, what's a problem
> here? You know, it's like PATH unix envvar - it is standard,
> but different systems and different users put different stuff there.
>
Yes, it is standard, well understood and behaves as follows:
1) the variables have proper names, such as LD_LIBRARY_PATH.
2) the variables except 1 value, or in rare circumstances multiple
values of 1 type (such as PATH).

The name alone "SYSTYPE" raises more question than answers. The type
of the system. Right.

DISTRO_LIBC


> >> Some distro needs switch libc's. Some needs to switch WMs.

DISTRO_LIBC=eglibc
to instruct the distribution to build (against) eglibc.

DISTRO_WM=twm

> >> 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).
> >>
Too confusing.

> > MACHINE and DISTRO are extremely well understood: they select one
> > option out of a list, and the name implies what you select.
>
> > Extremely user friendly.
>
> > SYSTYPE does not fulfill these two properties in your proposal.
>
>  ??? How it is not? Do you have a proposal for better name?
>
See all the reasoning above.

> >> > +0 for the making DISTRO_LIBC a global C library selector.
> >>
> >>   Gotcha! That's exactly what I'm trying to avoid - proliferation of
> >> adhoc distro config parameters! We have ANGSTROM_MODE now, supposedly
> >> FooNas will want to call it FOONAS_LIBC, with lots others alike. Then
> >>
> > No, "DISTRO_LIBC". Literally. Like Marcin set out more explicitly than I did.
> >> bitbake --distro=foo --systype=bar --machine=baz package
> >>
> > Argh. No!
>
>   Indeed? Maybe you even have arguments? ;-) Or rather, maybe you have
>

First you write "Exact format of what goes into SYSTYPE and its
semantics is up to distro" and then you affect bitbake (which is a
tool) with the distro-specifics as *options*??

> users? Please share, that's what I'm trying to solve here.
>
> >>   And nothing really precludes SYSTYPE to be not just "libc", but
> >> "libc,release", or "libc,release,wm=xfce", or
> >> "libc,release,wm=xfce,weird_user_config=some_file.conf".
> >>
> > Sorry, you didn't convince me, at all.
>
> > I strongly agree with Richard to either not do this (therefore my -2),
> > or either to define a sane namespace that some distro's might support,
> > agreeing with Marcin.
>
>   We somehow interpret differently what Richard wrote. Per my
> understanding, his concern was that it won't be clear if given feature
> will be supported by some distro, or no. SYSTYPE offers validation to
> solve this issue.
>
The concern is that users are not able to track which distro does, and
which distro does not support SYSTYPE, let alone the distro-specifics.

I think I fully understood your proposal (and your care for user
friendlier OE), but my first concerns fully remain.

SYSTYPE is not a good way forward.

Regards,
-- 
Leon

Re: [RFC] ANGSTROM_MODE -> SYSTYPE

[Marcin Juszkiewicz]

Dnia sobota, 15 grudnia 2007, Paul Sokolovsky napisał:

>    ANGSTROM_MODE config variable has proven to be very useful and
> successful feature during the Angstrom evolution. IMHO, it is worth
> generalization of its meaning and naming to become a generic
> additional OE distro configuration parameter. So, I'd like to propose
> it to be renamed to SYSTYPE, with the description "Select particular
> system variant of a distribution which supports such feature, e.g.,
> underlying libc type."

Basically I like idea of unifing this. In Poky we have POKYLIBC for it. 
But it should be in DISTRO_ namespace as this makes distro change.

>   Obviously, it wouldn't be limited to libc type, but intended to be a
> generic sub-parameter of a distro, 

DISTRO_LIBC

> it could be debug/release type, 

DISTRO_TYPE

> size type (minimal/standard/extended), 

This is handled by distro overrides when it comes to configurations 
(busybox, uclibc, kernel configs) and images content.

> whatever. 

DISTRO_* can be added at any time as long as they have sense.

> The usage idea is to have standard name for such generic parameter, plus
> semantically it should be expected that a distro allows to build
> different SYSTYPE's side-by-side in the same build dir (like Angstrom
> does for libc variants).

> And nothing really precludes SYSTYPE to be not just "libc", but
> "libc,release", or "libc,release,wm=xfce", or
> "libc,release,wm=xfce,weird_user_config=some_file.conf".

This is *SICK* as this really should be set in local.conf. Imagine how to 
handle something like this:

DISTRO=umbaumba-18.7 MACHINE=spitz SYSTYPE="uclibc 
uclibc_config=tweaks/uclibc.config release,wm=openbox 
openbox_config=tweaks/openbox.onfig kernel=tweaks/linux-rp-umbaumba 
kernel_config=tweaks/kernel/spitz.defconfig" bitbake 
umbaumba-default-image

All what this command do is possible with auto/local.conf files.


+1 from me for DISTRO_LIBC and good thought other DISTRO_ vars
-2 for me for SYSTYPE variable
-oo for SYSTYPE usage like command above

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

                 We are the Knights who say: MOVE.L USP,A1

Re: [RFC] ANGSTROM_MODE -> SYSTYPE

[Paul Sokolovsky]

Hello Marcin,

Sunday, December 16, 2007, 10:48:13 PM, you wrote:

> Dnia sobota, 15 grudnia 2007, Paul Sokolovsky napisał:

>>    ANGSTROM_MODE config variable has proven to be very useful and
>> successful feature during the Angstrom evolution. IMHO, it is worth
>> generalization of its meaning and naming to become a generic
>> additional OE distro configuration parameter. So, I'd like to propose
>> it to be renamed to SYSTYPE, with the description "Select particular
>> system variant of a distribution which supports such feature, e.g.,
>> underlying libc type."

> Basically I like idea of unifing this. In Poky we have POKYLIBC for it.
> But it should be in DISTRO_ namespace as this makes distro change.

>>   Obviously, it wouldn't be limited to libc type, but intended to be a
>> generic sub-parameter of a distro, 

> DISTRO_LIBC

>> it could be debug/release type, 

> DISTRO_TYPE

>> size type (minimal/standard/extended), 

> This is handled by distro overrides when it comes to configurations 
> (busybox, uclibc, kernel configs) and images content.

>> whatever. 

> DISTRO_* can be added at any time as long as they have sense.

>> The usage idea is to have standard name for such generic parameter, plus
>> semantically it should be expected that a distro allows to build
>> different SYSTYPE's side-by-side in the same build dir (like Angstrom
>> does for libc variants).

>> And nothing really precludes SYSTYPE to be not just "libc", but
>> "libc,release", or "libc,release,wm=xfce", or
>> "libc,release,wm=xfce,weird_user_config=some_file.conf".

> This is *SICK* as this really should be set in local.conf. Imagine how to
> handle something like this:

  That was just a display that such syntax (i.e. single var) doesn't have
any restrictions. The actual syntax of the value is fully offloaded to
a specific distro. And I don't expect any distro in OE mainline having
something more than scalar value soon.

> DISTRO=umbaumba-18.7 MACHINE=spitz SYSTYPE="uclibc 
> uclibc_config=tweaks/uclibc.config release,wm=openbox 
> openbox_config=tweaks/openbox.onfig kernel=tweaks/linux-rp-umbaumba 
> kernel_config=tweaks/kernel/spitz.defconfig" bitbake 
> umbaumba-default-image

> All what this command do is possible with auto/local.conf files.

  So, let it me recount it again: the talk is not just about renaming
ANGSTROM_MODE to something, but about defining a user-level, whitebox
parameters to configure OE build. We had a long and hot discussion
recently about making OE more friendly for novices and casual
developers. I was opponent of any patch/wrap measures, but something
should be done to make OE more easily configurable nonetheless.

  The approach I argue here is: let's define finite, small, easily
graspable set of parameters and then work towards making OE work out of
the box requiring a user to set just those parameters, and preferrably
set in easy and obvious way.

  Editing auto/local.conf and bunch of DISTRO_* parameters do not qualify
for this purpose, those are developers' stuff, requiring reading
lots of docs and good understanding of OE.

  Summing up, arguments for the original proposal:

1. One variable vs many: psychologically, it's much easier to remember
one setting than many. Knowledge that *all* additional configuration
is passed via one variable gives additional psychological boost that
you have powerful and flexible tool in your hand, and know that tool \
well enough to use it. (I mean only *whitebox* distro parameters here,
never a talk about replacing dozens of OE variables with the one;
developers will keep fiddling with all of them).
  Next, as I pointed, once we settle on the set of the OE whitebox
variables (and I really hope it will be this three-some of DISTRO,
<var_in_question>, MACHINE), it would be natural to allow to specify
them on bitbake command line. This would require finite and small set
of them.

2. SYSTYPE vs LONG_BUT_FULLY_CORRECT_VARIABLE_NAME: I love namespaces
and stuff myself, but again, with such paradigm, there would be 2
top-level namespaces: whitebox vars and blackbox vars. Whitebox vars
face large community of users, so there names should be short and
catchy, and not necessarily fit with blackbox var names. As an
example, distro code might parse SYSTYPE="release,glibc" and set
DISTRO_LIBC="glibc", DISTRO_TYPE="release" based on that, for peruse
by other parts of OE blackbox.


   So, renaming ANGSTROM_MODE to DISTRO_LIBC is obviously move in the
right direction, but let's consider if we're ready to move on wider front
at the same time. I personally already have in my tree changes which
allow to just check out OE and bitbake, have bitbake on the path,
create a build dir in well-known location, and then type

DISTRO=angsrom SYSTYPE=uclibc MACHINE=h4000 bitbake initramfs-bootmenu-image

or

DISTRO=angsrom MACHINE=hx4700 bitbake x11-image

or

DISTRO=generic-uclibc-opt MACHINE=wdmybook bitbake nano

or

DISTRO=openwrt-sdk MACHINE=brcm24 bitbake nano


And voila. No config file copying and editing. No
obscure environment variable setting. No wrapper scripts. No
Makefiles. It just works.


> +1 from me for DISTRO_LIBC and good thought other DISTRO_ vars
> -2 for me for SYSTYPE variable
> -oo for SYSTYPE usage like command above




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

Re: [RFC] ANGSTROM_MODE -> SYSTYPE

[Richard Purdie]

On Mon, 2007-12-17 at 00:31 +0200, Paul Sokolovsky wrote:
>    So, renaming ANGSTROM_MODE to DISTRO_LIBC is obviously move in the
> right direction, but let's consider if we're ready to move on wider front
> at the same time. I personally already have in my tree changes which
> allow to just check out OE and bitbake, have bitbake on the path,
> create a build dir in well-known location, and then type
> 
> DISTRO=angsrom SYSTYPE=uclibc MACHINE=h4000 bitbake initramfs-bootmenu-image
> 
> or
> 
> DISTRO=angsrom MACHINE=hx4700 bitbake x11-image
> 
> or
> 
> DISTRO=generic-uclibc-opt MACHINE=wdmybook bitbake nano
> 
> or
> 
> DISTRO=openwrt-sdk MACHINE=brcm24 bitbake nano
> 
> 
> And voila. No config file copying and editing. No
> obscure environment variable setting. No wrapper scripts. No
> Makefiles. It just works.

I'm not convinced about this :(. Why?

The appearance of a standard DISTRO_LIBC variable implies that "glibc"
and "uclibc" options are always going to work. What if the distro
doesn't support one of them? Is a bug report about some parameter passed
to this variable not working for a given distro valid?

The point is that all this configuration is distro specific. It should
be up to the distro to decide what kind of users it wishes to cater for
and how to enable those users to use OE. 

If Angstrom wants single variable configuration (or triplet variable
configuration with MACHINE, DISTRO, DISTRO_MODE/whatever) then thats
fine. Rolling that out onto every other distro breaks the distro
abstraction though.

If you want to add some common code which handles such a variable
variable that is also fine. I just worry about making it a generic and
mandatory variable, I think it should remain distro specific (and hence
up to the maintainers of a given distro).

Cheers,

Richard

Re: [RFC] ANGSTROM_MODE -> SYSTYPE

[Paul Sokolovsky]

Hello Richard,

Monday, December 17, 2007, 12:58:31 AM, you wrote:

> On Mon, 2007-12-17 at 00:31 +0200, Paul Sokolovsky wrote:
>>    So, renaming ANGSTROM_MODE to DISTRO_LIBC is obviously move in the
>> right direction, but let's consider if we're ready to move on wider front
>> at the same time. I personally already have in my tree changes which
>> allow to just check out OE and bitbake, have bitbake on the path,
>> create a build dir in well-known location, and then type
>> 
>> DISTRO=angsrom SYSTYPE=uclibc MACHINE=h4000 bitbake initramfs-bootmenu-image
>> 
>> or
>> 
>> DISTRO=angsrom MACHINE=hx4700 bitbake x11-image
>> 
>> or
>> 
>> DISTRO=generic-uclibc-opt MACHINE=wdmybook bitbake nano
>> 
>> or
>> 
>> DISTRO=openwrt-sdk MACHINE=brcm24 bitbake nano
>> 
>> 
>> And voila. No config file copying and editing. No
>> obscure environment variable setting. No wrapper scripts. No
>> Makefiles. It just works.

> I'm not convinced about this :(. Why?

> The appearance of a standard DISTRO_LIBC variable implies that "glibc"
> and "uclibc" options are always going to work.

  Exactly. That's another reason not to create DISTRO_LIBC, or at
least, not to treat it as something more than internal setting.

> What if the distro
> doesn't support one of them? Is a bug report about some parameter passed
> to this variable not working for a given distro valid?

  This - validation of SYSTYPE setting - was already discussed
actually. To remind, quick and easy way to do it is to make distros
which support SYSTYPE to set SYSTYPES_SUPPORTED to, say,
"glibc eglibc uclibc". If SYSTYPES_SUPPORTED is not set, while
SYSTYPE, sanity.bbclass will barf out. Otherwise, it will check that
${SYSTYPE} appears in ${SYSTYPES_SUPPORTED} and barf out otherwise.

  The drawback is that it puts artificial constraints on ${SYSTYPE}
syntax. More general way would be to have SYSTYPE_SUPPORTED. If unset,
non-empty SYSTYPE causes sanity error. Otherwise, validation of its
value is left to the distro config/class files.

> The point is that all this configuration is distro specific. It should
> be up to the distro to decide what kind of users it wishes to cater for
> and how to enable those users to use OE.

  Yes, but as recent discussion showed, users doubt that, and think
that *OE* (not just a distro) should be more friendly to them. It
would be unwise to ignore that - there were many voices with different
usecases. To address this, OE should provide best practices on user-facing
configuration methods (in particular).

> If Angstrom wants single variable configuration (or triplet variable
> configuration with MACHINE, DISTRO, DISTRO_MODE/whatever) then thats
> fine. Rolling that out onto every other distro breaks the distro
> abstraction though.

  It won't be "roll out onto". It will be a best practice worked out
over long time by a big distro. We just need to polish it up to be
a real best practice, not just something which could be done.

> If you want to add some common code which handles such a variable
> variable that is also fine. I just worry about making it a generic and
> mandatory variable, I think it should remain distro specific (and hence
> up to the maintainers of a given distro).

  Let's put it that way: if a distro has some high-level,
user-adjustable setting(s) to tweak, they are advised to allow to do
this via SYSTYPE. They are free not to use it, or to use any other
configuration method of course. But if we agree on such a
recommendation for SYSTYPE, and distros actually will use it, that
will make users' life easier, for example, we will be able to write
2-paragraph Quick Start instructions which will actually describe 90%
of what someone, who is not a distro engineer, may need to know about
OE to get his initial tasks done.

> Cheers,

> Richard

[]

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