[oe] [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 at gmail.com