[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