[RFC] base_less_or_equal() for numerical value testing in OE

[RFC] base_less_or_equal() for numerical value testing in OE

[Paul Sokolovsky]

Hello openembedded-devel,

  OE has base_conditional() function which is kind of C's ternary ?:
operator, with equality of two value as a condition (it is a bit
misnamed in this respect, it'd rather be base_equals() ).

  There're few other such conditional functions, for example for set
containment check. What we lack however is simple numeric less/greater
check. Having it would be important for us to continue started work of
using generalized machine feature checks to decide on some aspects of
image/package building, instead of hardcoding tests for specific
machines.

  So, hitting such need yet another time, I proceeded to add
base_less_or_equal() to base.bbclass, and used it to tweak locale
package install for Angstrom:

# Also, it appears that no locales fit in 16Mb for now. "C" locale rules!
IMAGE_LINGUAS = '${@base_less_or_equal("ROOT_FLASH_SIZE", "16", "", "en-gb", d)}'

  This shows common usecase, and makes clear why exactly
base_less_or_equal() was added - I don't have a usecase for
base_less() now at all.


  This code was committed, as it doesn't affect any existing aspect of
OE. Please feel free to tweak it, and of course use!


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

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Koen Kooi]

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

Paul Sokolovsky schreef:

>   This code was committed, as it doesn't affect any existing aspect of
> OE. Please feel free to tweak it, and of course use!

So this isn't an RFC, just a statement of fact
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFF5JayMkyGM64RGpERAr3xAJ9GmFW1O1X4UtnMtWdERJwNagHo6QCfaexb
C8qQu91uU9fxaC9iOs4uDdU=
=NDpg
-----END PGP SIGNATURE-----

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Richard Purdie]

On Tue, 2007-02-27 at 22:35 +0200, Paul Sokolovsky wrote:
> This code was committed, as it doesn't affect any existing aspect of
> OE. Please feel free to tweak it, and of course use!

So its not really a RFC, is it? ;-)

I think base_conditional was added but left pretty dumb since we worried
that if it was too generic it might get too many users. Inline python in
the variables hits bitbake and parsing hard and its not something I'd
like to encourage. Holger might have more specific comments. There are
usually better ways to achieve the end result in a more bitbake like
way. Also, personally I find the inline python really hard to read too.

If we are going to do it, I'd prefer to see a set functions in their own
class inherited by base.

Yes, I realise I was guilty of adding a couple of these functions with
task-base. They're mainly used in a couple of specific .bb files rather
than the core classes and hopefully their usefulness outweights any
speed penalty though...

Cheers,

Richard 

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Paul Sokolovsky]

Hello Koen,

Tuesday, February 27, 2007, 10:38:10 PM, you wrote:

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

> Paul Sokolovsky schreef:

>>   This code was committed, as it doesn't affect any existing aspect of
>> OE. Please feel free to tweak it, and of course use!

> So this isn't an RFC, just a statement of fact

  I had it in my tree for a week now, tested, so just decided to
commit it, taking into account that it follows existing
base_conditional() signature, doesn't affect anything else, and
offers capability both needed and simple.

>> Please feel free to tweak it, and of course use!

   I mean this. If there're better ideas on naming, etc., these can
be easily applied or discussed. We may want to discuss the whole
situation with such checks in OE: anything else needed/missing? are
we satisfied with such a solution for checks? etc, etc.



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

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Paul Sokolovsky]

Hello Richard,

Tuesday, February 27, 2007, 10:49:01 PM, you wrote:

> On Tue, 2007-02-27 at 22:35 +0200, Paul Sokolovsky wrote:
>> This code was committed, as it doesn't affect any existing aspect of
>> OE. Please feel free to tweak it, and of course use!

> So its not really a RFC, is it? ;-)

  Disapprove is easy if it's wrong.

> I think base_conditional was added but left pretty dumb since we worried
> that if it was too generic it might get too many users. Inline python in
> the variables hits bitbake and parsing hard and its not something I'd
> like to encourage. Holger might have more specific comments. There are
> usually better ways to achieve the end result in a more bitbake like
> way. Also, personally I find the inline python really hard to read too.

> If we are going to do it, I'd prefer to see a set functions in their own
> class inherited by base.

> Yes, I realise I was guilty of adding a couple of these functions with
> task-base. They're mainly used in a couple of specific .bb files rather
> than the core classes and hopefully their usefulness outweights any
> speed penalty though...

  Well, that's good explanation from the point of view of birbake's
limitation we (still) have, but I'd like to approach from another side -
of what usecases we face. So, there was one case when
base_conditional() was used for checking ROM size too, but Marcin
replaced it with checks for specific machine models, exactly because
we had only ==, and not < or <=. And here's another case of fitting
angstrom-gpe-image into 16Mb (actual target is h3600, but I'd like
this time to do it in more scalable way then proliferate *_<machine>
stuff).

  I can quickly hand out 2 alternative solutions for this image size
problem: 1) define *-micro, *-normal, *-maxi bunch of images, 2)
assign each package a numeric priority, and package image based on
that (this "solution" is mentioned mostly for fun, of course).

  Well, both of them are more effortful than adding few base_*() at
right places. Solution #1 is still seems the most correct, of course,
but using conditionals may be seen as incremental step towards it.


  If we started on this topic (handling machine features in consistent
way, and establish best practices), let me dump another thing I ponder
for long time, before I'll start to code something - screen size problem.

  IMHO, "smallscreen" and "bigscreen" heuristic designators we use now
are the best thing we could have in our situation. There were
proposals on adding absolute screen properties, but IMHO, that
wouldn't give us much use, because 1) for most machines values will be
still approximate at best, and 2) we'd quickly decide that it's cool that
we have that info now, but bitbake sucks, and it's too inefficient to
actually use those info, so we shouldn't use it.

  And besides, simple "smallscreen" vs "bigscreen" dichotomy
corresponds to what packages actually provides in real life - mostly,
just 2 sets of icons, etc.

  What bothers me here however is that we uselessly package the same data
over and over again in machine-specific packages, plus each such recipe
must be modified for each new machine added to OE. Doesn't scale.

  What about following solution: define 2 "virtual" *archs* -
smallscreen and bigscreen. Make a convention that such archs can be
applied only to "data" ipk's. Then, a machine will just specify to
which virtual screen arch it belongs, like:

hx4700: PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5te iwmmxt bigscreen"
h4000: PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5te iwmmxt smallscreen"

  Voila, matching of actual bigsreen/smallscreen package will be done by
ipkg.

> Cheers,

> Richard 




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

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Koen Kooi]

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

Paul Sokolovsky schreef:

>   Well, that's good explanation from the point of view of birbake's
> limitation we (still) have, but I'd like to approach from another side -
> of what usecases we face. So, there was one case when
> base_conditional() was used for checking ROM size too,

Checking for ROM size is bogus, since you can't write to it anyway, and should be removed.
I suspect you mean 'flash size'.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFF5KVTMkyGM64RGpERAsZbAKC9n7KBtnxojUdF40WOUxQdnULchwCgry0h
moaj6DeDPPLbCphzHl/yyPE=
=mzUU
-----END PGP SIGNATURE-----

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Richard Purdie]

On Tue, 2007-02-27 at 23:31 +0200, Paul Sokolovsky wrote:
> > So its not really a RFC, is it? ;-)
> 
>   Disapprove is easy if it's wrong.

That isn't a good justification. Please ask first if you intend for
comments, then commit after discussion.

>   If we started on this topic (handling machine features in consistent
> way, and establish best practices), let me dump another thing I ponder
> for long time, before I'll start to code something - screen size problem.
> 
>   IMHO, "smallscreen" and "bigscreen" heuristic designators we use now
> are the best thing we could have in our situation. There were
> proposals on adding absolute screen properties, but IMHO, that
> wouldn't give us much use, because 1) for most machines values will be
> still approximate at best, and 2) we'd quickly decide that it's cool that
> we have that info now, but bitbake sucks, and it's too inefficient to
> actually use those info, so we shouldn't use it.

I never said 2). I said we should keep in mind the impact on parsing
speed. We've gone to great lengths to improve it and I'm simply warning
there is a compromise. 

I don't want to see OE metadata turning into inlined python. If we find
we need to do that, something is wrong with the metadata format and we
should improve it.

The metadata format has been relatively static for a long time as the
bitbake developers have been conservative in certain areas. If we have a
need to improve it, I'm open to suggestions on that. Inlining python to
work around its limitations is not the correct solution.

>   And besides, simple "smallscreen" vs "bigscreen" dichotomy
> corresponds to what packages actually provides in real life - mostly,
> just 2 sets of icons, etc.
> 
>   What bothers me here however is that we uselessly package the same data
> over and over again in machine-specific packages, plus each such recipe
> must be modified for each new machine added to OE. Doesn't scale.

So automate those sites so they run off a machine specified variable.
You shouldn't have to hack the .bb's when adding a new machine (apart
from maybe things like fstab in base-files).

The actual packaging then becomes the only issue but that is only a
minor issue in the big picture.

I've slowly being try to remove machine specific packages too
(tslib-conf is no longer machine specific in the standard case).

> hx4700: PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5te iwmmxt bigscreen"
> h4000: PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5te iwmmxt smallscreen"
> 
>   Voila, matching of actual bigsreen/smallscreen package will be done by
> ipkg.

No. Adding architectures for every machine feature is just insane. You
need to find a better way to do it. Think about what you're suggesting
for a minute. 

Regards,

Richard

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Paul Sokolovsky]

Hello Koen,

Tuesday, February 27, 2007, 11:40:35 PM, you wrote:

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

> Paul Sokolovsky schreef:

>>   Well, that's good explanation from the point of view of birbake's
>> limitation we (still) have, but I'd like to approach from another side -
>> of what usecases we face. So, there was one case when
>> base_conditional() was used for checking ROM size too,

> Checking for ROM size is bogus, since you can't write to it anyway, and should be removed.
> I suspect you mean 'flash size'.

  Sure. ROOT_FLASH_SIZE is the parameter being checked. And I hope
layman's using of "ROM" and "Flash" as synonyms won't confuse real pro's.
In particular, I hope that if a vendor with mask-ROM based design will
review OE as their software integration solution, the fact that the
parameter is called "ROOT_FLASH_SIZE", won't make them think they
can't be served by OE ;-).


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

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Koen Kooi]

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

Paul Sokolovsky schreef:
> Hello Richard,
> 
> Tuesday, February 27, 2007, 10:49:01 PM, you wrote:
> 
>> On Tue, 2007-02-27 at 22:35 +0200, Paul Sokolovsky wrote:
>>> This code was committed, as it doesn't affect any existing aspect of
>>> OE. Please feel free to tweak it, and of course use!
> 
>> So its not really a RFC, is it? ;-)
> 
>   Disapprove is easy if it's wrong.

To illustrate the point: your commit broke building for machines that don't set root flash
size (e.g. machines that don't have flash).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFF5X70MkyGM64RGpERAiiOAJ9BQhhTkQRDjkBZOFwiSEBQMXofXQCgt+3B
B3ddYIOI+Blw0Z5tX9R0WfE=
=E2kF
-----END PGP SIGNATURE-----

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Paul Sokolovsky schreef:
>> Hello Richard,
>>
>> Tuesday, February 27, 2007, 10:49:01 PM, you wrote:
>>
>>> On Tue, 2007-02-27 at 22:35 +0200, Paul Sokolovsky wrote:
>>>> This code was committed, as it doesn't affect any existing aspect of
>>>> OE. Please feel free to tweak it, and of course use!
>>> So its not really a RFC, is it? ;-)
>>   Disapprove is easy if it's wrong.
> 
> To illustrate the point: your commit broke building for machines that don't set root flash
> size (e.g. machines that don't have flash).

To expand a little, I was getting messages related to ROOT_FLASH_SIZE 
when building for the EFIKA. The EFIKA has an IDE slot we can install 
different devices (with different sizes) in (hard drive, CF on adapter, 
etc), so it does not make sense to define ROOT_FLASH_SIZE for this machine.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Paul Sokolovsky]

Hello Richard,

(sorry for delay with response, I had system stability issues)

Wednesday, February 28, 2007, 12:03:50 AM, you wrote:

> On Tue, 2007-02-27 at 23:31 +0200, Paul Sokolovsky wrote:
>> > So its not really a RFC, is it? ;-)
>> 
>>   Disapprove is easy if it's wrong.

> That isn't a good justification. Please ask first if you intend for
> comments, then commit after discussion.

  Ok. Sorry for being hasty this time.

>>   If we started on this topic (handling machine features in consistent
>> way, and establish best practices), let me dump another thing I ponder
>> for long time, before I'll start to code something - screen size problem.
>> 
>>   IMHO, "smallscreen" and "bigscreen" heuristic designators we use now
>> are the best thing we could have in our situation. There were
>> proposals on adding absolute screen properties, but IMHO, that
>> wouldn't give us much use, because 1) for most machines values will be
>> still approximate at best, and 2) we'd quickly decide that it's cool that
>> we have that info now, but bitbake sucks, and it's too inefficient to
>> actually use those info, so we shouldn't use it.

> I never said 2). I said we should keep in mind the impact on parsing
> speed. We've gone to great lengths to improve it and I'm simply warning
> there is a compromise. 

> I don't want to see OE metadata turning into inlined python. If we find
> we need to do that, something is wrong with the metadata format and we
> should improve it.

> The metadata format has been relatively static for a long time as the
> bitbake developers have been conservative in certain areas. If we have a
> need to improve it, I'm open to suggestions on that. Inlining python to
> work around its limitations is not the correct solution.

  Yes, I would think along that direction too. We have own bitbake
language/syntax and yet reduce to using cumbersome syntax for
conditionals, etc. Yet, I don't have any direct suggestions how to
handle that better. It's apparently depends more on high-level
usescases for OE/bitbake, and the change in question is just small
incremental step towards better support for high-level requirements
(like ability to build rootfs's limited to specific size).

>>   And besides, simple "smallscreen" vs "bigscreen" dichotomy
>> corresponds to what packages actually provides in real life - mostly,
>> just 2 sets of icons, etc.
>> 
>>   What bothers me here however is that we uselessly package the same data
>> over and over again in machine-specific packages, plus each such recipe
>> must be modified for each new machine added to OE. Doesn't scale.

> So automate those sites so they run off a machine specified variable.
> You shouldn't have to hack the .bb's when adding a new machine (apart
> from maybe things like fstab in base-files).

  Well, that's good idea to start with, I'll into this.

> The actual packaging then becomes the only issue but that is only a
> minor issue in the big picture.

  Yes, but the one easily identifiable as being unclean. I don't say
it's high-priority, but worth keeping in mind that such issue exists.

> I've slowly being try to remove machine specific packages too
> (tslib-conf is no longer machine specific in the standard case).

  Nice! Let's move this forward then, and think about guidelines how
to handle different cases of machine-specificity. One bold example is
udevd, which (at least last time I checked) was machine-specific only
because for h2200, there was adhoc rule file added to override PCMCIA
voltages settings for some cards. As it is only additional file,
there's really no need to contaminate base package, and instead I can
imagine following ways to resolve it:

1. Add that udevd rule to common machine config package, i.e.
base-files.
2. Go even more clean and granular, and create own package for this
rule, and MACHINE_EXTRA_RRECOMMEND it.

  What do you think?


>> hx4700: PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5te iwmmxt bigscreen"
>> h4000: PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5te iwmmxt smallscreen"
>> 
>>   Voila, matching of actual bigsreen/smallscreen package will be done by
>> ipkg.

> No. Adding architectures for every machine feature is just insane.

  Well, I understand that I raise few features at the same time, and
it may be a bit confusing to follow thru them, but actual topic of all
this - how to improve machine metadata handling in OE.

  So, I don't speak about adding virtual arch for every machine
feature, but *only* for the screen size. That's the machine feature
which seems as possibly calling for that - as it's not uncommon to
supply image resources for different resolutions (i.e. these
smallscreen/bigscreen arch packages won't be just for app), plus image
resources are usually big enough to warrant placement into own
package.

> You
> need to find a better way to do it. Think about what you're suggesting
> for a minute.

  Again, if limit that to screen size property only, it's not that
bad.

  But obviously, that's not the only possible solution. Other approach
would be to consider smallscreen/bigscreen distinction just as a kind
of app theming. So, there may be red color theme, blue color theme,
or smallscreen or bigscreen theme. I'm not sure if ipkg handles OR
dependencies, but we obviously can emulate them with Provides:

Package: foo
Depends: foo-data

Package: foo-data-smallscreen
Provides: foo-data

Package: foo-data-bigscreen
Provides: foo-data


  Drawback of this approach is complication of app installation - user
will need to explicitly select which data package to install, whereas
with "virtual arch" approach this would be handled by ipkg
automagically.

> Regards,

> Richard



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

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Paul Sokolovsky]

Hello Koen,

Wednesday, February 28, 2007, 3:09:08 PM, you wrote:

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

> Paul Sokolovsky schreef:
>> Hello Richard,
>> 
>> Tuesday, February 27, 2007, 10:49:01 PM, you wrote:
>> 
>>> On Tue, 2007-02-27 at 22:35 +0200, Paul Sokolovsky wrote:
>>>> This code was committed, as it doesn't affect any existing aspect of
>>>> OE. Please feel free to tweak it, and of course use!
>> 
>>> So its not really a RFC, is it? ;-)
>> 
>>   Disapprove is easy if it's wrong.

> To illustrate the point: your commit broke building for machines that don't set root flash
> size (e.g. machines that don't have flash).

  Oops, sorry, I actually had a patch to set the default value in
bitbake.conf, missed to commit. Thanks for adding it. Except that
common usecase would be to check if that value is less than a
threshold, and don't include some package then. So, default value
should be some reasonably big, not 0. I'll commit such change.

[]

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

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Richard Purdie]

On Mon, 2007-03-05 at 01:30 +0200, Paul Sokolovsky wrote:
> Wednesday, February 28, 2007, 12:03:50 AM, you wrote:
> > On Tue, 2007-02-27 at 23:31 +0200, Paul Sokolovsky wrote:
> > I've slowly being try to remove machine specific packages too
> > (tslib-conf is no longer machine specific in the standard case).
> 
>   Nice! Let's move this forward then, and think about guidelines how
> to handle different cases of machine-specificity. One bold example is
> udevd, which (at least last time I checked) was machine-specific only
> because for h2200, there was adhoc rule file added to override PCMCIA
> voltages settings for some cards. 

Well, I *hate* udev being machine specific. It was made machine specific
due to the different automounter blacklist files. Also, personally, I'd
prefer a whitelist, I've just never had the time to implement it. Or rip
it all out and write a better automounter scipt...

> As it is only additional file,
> there's really no need to contaminate base package, and instead I can
> imagine following ways to resolve it:
> 
> 1. Add that udevd rule to common machine config package, i.e.
> base-files.
> 2. Go even more clean and granular, and create own package for this
> rule, and MACHINE_EXTRA_RRECOMMEND it.

I'd always been thinking of splitting it out to a separate package. No
need to touch MACHINE_EXTRA_RRECOMMEND, just have udev RRECOMMEND it.

> >> hx4700: PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5te iwmmxt bigscreen"
> >> h4000: PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5te iwmmxt smallscreen"
> >> 
> >>   Voila, matching of actual bigsreen/smallscreen package will be done by
> >> ipkg.
> 
> > No. Adding architectures for every machine feature is just insane.
> 
>   Well, I understand that I raise few features at the same time, and
> it may be a bit confusing to follow thru them, but actual topic of all
> this - how to improve machine metadata handling in OE.
> 
>   So, I don't speak about adding virtual arch for every machine
> feature, but *only* for the screen size. That's the machine feature
> which seems as possibly calling for that - as it's not uncommon to
> supply image resources for different resolutions (i.e. these
> smallscreen/bigscreen arch packages won't be just for app), plus image
> resources are usually big enough to warrant placement into own
> package.

You only ask for screen size but I can guarantee that wouldn't be the
last request. I'm dead set against this.

>   But obviously, that's not the only possible solution. Other approach
> would be to consider smallscreen/bigscreen distinction just as a kind
> of app theming. So, there may be red color theme, blue color theme,
> or smallscreen or bigscreen theme. I'm not sure if ipkg handles OR
> dependencies, but we obviously can emulate them with Provides:
> 
> Package: foo
> Depends: foo-data
> 
> Package: foo-data-smallscreen
> Provides: foo-data
> 
> Package: foo-data-bigscreen
> Provides: foo-data
> 
> 
>   Drawback of this approach is complication of app installation - user
> will need to explicitly select which data package to install, whereas
> with "virtual arch" approach this would be handled by ipkg
> automagically.

The virtual-arch approach is a none starter IMO. I'd be interested to
know how ipkg handles the above scenario.

I don't think machine specific packages are that big a deal in
themselves, I do agree that having to edit .bb files for each machine as
standard is wrong though.

Cheers,

Richard

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Koen Kooi]

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

Richard Purdie schreef:
> On Mon, 2007-03-05 at 01:30 +0200, Paul Sokolovsky wrote:

>>>> hx4700: PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5te iwmmxt bigscreen"
>>>> h4000: PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5te iwmmxt smallscreen"
>>>>
>>>>   Voila, matching of actual bigsreen/smallscreen package will be done by
>>>> ipkg.
>>> No. Adding architectures for every machine feature is just insane.
>>   Well, I understand that I raise few features at the same time, and
>> it may be a bit confusing to follow thru them, but actual topic of all
>> this - how to improve machine metadata handling in OE.
>>
>>   So, I don't speak about adding virtual arch for every machine
>> feature, but *only* for the screen size. That's the machine feature
>> which seems as possibly calling for that - as it's not uncommon to
>> supply image resources for different resolutions (i.e. these
>> smallscreen/bigscreen arch packages won't be just for app), plus image
>> resources are usually big enough to warrant placement into own
>> package.
> 
> You only ask for screen size but I can guarantee that wouldn't be the
> last request. I'm dead set against this.

Me too, since you will get something like this:

application_1.4.5-r5_bigscreen.ipk
application_1.4.5-r5_ppc603e.ipk
application_1.4.5-r5_armv5te.ipk
application_1.4.5-r5_smallscreen.ipk

Now Marcin wants to install 'application' on his webpad and it doesn't run. Why? Because
'application_1.4.5-r5_bigscreen.ipk' secretly is ARM instead of x86.

regards,

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

iD8DBQFF6783MkyGM64RGpERAupWAJ9vHpWTx5ctFNIY0oyU/vm8TUFylgCaAzgE
17abF4sgH/AJjuCwhhEuCqs=
=D9V6
-----END PGP SIGNATURE-----

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Marcin Juszkiewicz]

Dnia poniedziałek, 5 marca 2007, Koen Kooi napisał:
> Richard Purdie schreef:
> > On Mon, 2007-03-05 at 01:30 +0200, Paul Sokolovsky wrote:

> > You only ask for screen size but I can guarantee that wouldn't be the
> > last request. I'm dead set against this.

> Me too, since you will get something like this:

-1 from me too

> application_1.4.5-r5_bigscreen.ipk
> application_1.4.5-r5_ppc603e.ipk
> application_1.4.5-r5_armv5te.ipk
> application_1.4.5-r5_smallscreen.ipk

> Now Marcin wants to install 'application' on his webpad and it doesn't
> run. Why? Because 'application_1.4.5-r5_bigscreen.ipk' secretly is ARM
> instead of x86.

And what is bigscreen? VGA? SVGA? XGA? or maybe 1680x1050 which I use 
under OE/x86 chroot system?

Instead of using crypto names like smallscreen/bigscreen we should use 
MACHINE_ namespace instead:

MACHINE_SCREEN_RESOLUTION = "vga/svga/qvga/xga/wxga/hvga" etc
MACHINE_SCREEN_DPI = "100/280/75"

Because Neo1973 is smallscreen (2.8") but VGA (so bigscreen). I do not 
feel good with using full AbiWord on it but probably AbiWord embedded 
will be OK.

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

         Real programmers don't document.
         If it was hard to write, it should be hard to understand.

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Paul Sokolovsky]

Hello Koen,

Monday, March 5, 2007, 8:56:56 AM, you wrote:

[]

>> You only ask for screen size but I can guarantee that wouldn't be the
>> last request. I'm dead set against this.

> Me too, since you will get something like this:

> application_1.4.5-r5_bigscreen.ipk
> application_1.4.5-r5_ppc603e.ipk
> application_1.4.5-r5_armv5te.ipk
> application_1.4.5-r5_smallscreen.ipk

> Now Marcin wants to install 'application' on his webpad and it doesn't run. Why? Because
> 'application_1.4.5-r5_bigscreen.ipk' secretly is ARM instead of x86.

  This was covered in my original rundown of how that could be
implemented. I proposed to have convention that smallscreen/datascreen
virtual archs may be applied only to data packages (whose arch would
be 'all' otherwise). Obviously, this can be enforced by insane.class.

  So, it would be:

application_1.4.5-r5_ppc603e.ipk
application_1.4.5-r5_armv5te.ipk
+
application-data_1.4.5-r5_bigscreen.ipk
application-data_1.4.5-r5_smallscreen.ipk

> regards,

> Koen

[]

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

Re: [RFC] base_less_or_equal() for numerical value testing in OE

[Paul Sokolovsky]

Hello Marcin,

Monday, March 5, 2007, 10:12:43 AM, you wrote:

> Dnia poniedziałek, 5 marca 2007, Koen Kooi napisał:
>> Richard Purdie schreef:
>> > On Mon, 2007-03-05 at 01:30 +0200, Paul Sokolovsky wrote:

>> > You only ask for screen size but I can guarantee that wouldn't be the
>> > last request. I'm dead set against this.

>> Me too, since you will get something like this:

> -1 from me too

>> application_1.4.5-r5_bigscreen.ipk
>> application_1.4.5-r5_ppc603e.ipk
>> application_1.4.5-r5_armv5te.ipk
>> application_1.4.5-r5_smallscreen.ipk

>> Now Marcin wants to install 'application' on his webpad and it doesn't
>> run. Why? Because 'application_1.4.5-r5_bigscreen.ipk' secretly is ARM
>> instead of x86.

> And what is bigscreen? VGA? SVGA? XGA? or maybe 1680x1050 which I use 
> under OE/x86 chroot system?

> Instead of using crypto names like smallscreen/bigscreen we should use
> MACHINE_ namespace instead:

> MACHINE_SCREEN_RESOLUTION = "vga/svga/qvga/xga/wxga/hvga" etc
> MACHINE_SCREEN_DPI = "100/280/75"

  I spelled my IMHO on this already too:
http://lists.linuxtogo.org/pipermail/openembedded-devel/2007-February/001539.html


  Let me factor it out if that mail was too long:

"IMHO, "smallscreen" and "bigscreen" heuristic designators we use now
are the best thing we could have in our situation. There were
proposals on adding absolute screen properties, but IMHO, that
wouldn't give us much use, because 1) for most machines values will be
still approximate at best, and 2) we'd quickly decide that it's cool that
we have that info now, but bitbake sucks, and it's too inefficient to
actually use those info, so we shouldn't use it.
  And besides, simple "smallscreen" vs "bigscreen" dichotomy
corresponds to what packages actually provides in real life - mostly,
just 2 sets of icons, etc."

  So, why I'm personally proponent of using objective parameters
whenever possible, in this case, using subjective, heuristic values
like "smallscreen" and "bigscreen" will save us from interpretation
complexities.



  As for definition of what "smallscreen" and "bigscreen", it must be
simple and just capture what we already have:

"There're guidelines (see appendix 1) of choosing
smallscreen/bigscreen for a given display device, plus, as usual, new
devices should be consistent with already existent assignments. But
ultimately, the selection is upon machine maintainer's choice and
consciousness.

Appendix 1:
1. If display device has relatively low DPI resolution, "smallscreen"
is a good choice regardless of actual pixel dimensions, as that will
allow to save screen real estate for more user information.
2. If display device has relatively low (sub-VGA) pixel dimensions,
use "smallscreen" as it is just too small to use bigger fonts, icons,
etc.
3. If display device has relatively high DPI resolution, use
"bigscreen" to save users' health.
4. If display device has relatively pixel dimensions, and following
guideline #1 will lead to awkward usability (like, easily
distinguishable for eyes icons, but which still can be lost in big
screen space), use "bigscreen"
"


> Because Neo1973 is smallscreen (2.8") but VGA (so bigscreen). I do not
> feel good with using full AbiWord on it but probably AbiWord embedded 
> will be OK.

  So, this is more or less subjective already (as full AbiWord could
be run on VGA, and some people would vote for "fullness"). But if
we'll try to express this subjectiveness in terms of the absolute
parameters, we'll at first will get mess and inconsistency, and long
time will be required to establish sane guidelines.




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