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

Phil Blundell pb at reciva.com
Wed Nov 26 17:40:14 UTC 2008


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.

p.






More information about the Openembedded-devel mailing list