[oe] preferred-provider at the image level a.k.a why is all this fso stuff in my non-fso image

[Koen Kooi]

On 26-11-08 18:40, Phil Blundell wrote:
> On Wed, 2008-11-26 at 17:55 +0100, Michael 'Mickey' Lauer wrote:
>> Sounds good overall, however there is still the problem with things like e.g.
>> gpsd. If you remove fso-gpsd's RPROVIDES=gspd, then anything that rdepends on
>> gpsd will bring us gpsd back into the [fso-]image, hence we have a conflict
>> again.
>
> It sounds like you have a namespacing problem here.  If there are
> packages which need to depend on some abstract gpsd API or ABI, they
> should probably be Depending on "virtual/gpsd" or the like and this
> virtual package should be Provided by both gpsd and fso-gpsd.
>
> Semi-virtual packages (i.e. a given name existing both as a concrete
> package and as a Provides: in some other package) basically do not work:
> this is partly an implementation problem in opkg but there is also a
> fundamentally insoluble problem with versioning.  About the only time
> that adding a Provides: for the same name as an existing concrete
> package is the right thing to do, is when one package completely
> supercedes each other; in this case you would generally also say that
> the new one Replaces: and Conflicts: with the old one.

Conflicts: + Replaces: hits another bug in opkg, it will silently pick 
'fso-foo' over 'foo' when both are in deploy (e.g. build fso-image for 
om-gta02 and x11-image-with-gpsd for om-gta01). We hit this problem when 
the matchbox-*2 was added from poky.
The good news is that opkg is maintained now so this problem can be fixed :)

regards,

Koen