[oe] [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