[oe] Problems if several packages exist in deploy/ipk/${MACHINE} that RPROVIDE the same

[Julian Pietron]

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

Hallo,

I've got some problems with RPROVIDES. This is my situation:

I version an overlay to release-2011.03 with git, and there are several
branches that mark different releases of my ROMs (e.g., 1.1, 1.2, 1.3).
The situation occurs, that branch 1.1 uses mesa-xlib as
PREFERRED_PROVIDER_virtual/libgl, while branch 1.2 uses mesa-dri.
Because sometimes I build packages for a 1.1.x bugfix release and
sometimes I build them for 1.2.x bugfix releases, both packages could
possibly exist as OPKG-Packages in deploy/ipk/${MACHINE}/.
If I build an image which contains virtual/libgl in IMAGE_INSTALL,
bitbake does not necessarily pull the package that is currently (for the
currently checked out branch), which would be mesa-dri for branch 1.2,
but pulls mesa-xlib instead, although it is listed as PREFERRED_PROVIDER
for 1.1 branch only.
My suspicion is, that opkg is somehow confused as both packages contain
a Provides for virtual/libgl in their metadata and doesn't know which
one to choose although I specified it with PREFERRED_PROVIDER. It seems
to me, that opkg somehow doesn't respect these setting.
I also observed this problem with other virtuals than virtual/libgl, so
the problem isn't limited to this virtual only.

Is this a known problem with having several packages Providing the same
virtuals built at the same time, or is there a way to solve this problem?

Thanks,
Julian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOeaudAAoJENidYKvYQHlQYYsQAJfKcI2E68fOnPhahNybCpvG
QWoW5hsStA39jWeGLmDwEdsHBsijBk6+wFw8cfNmq5YqdkUUpFv90CIl4P5/XTej
FlEN9Fxc1Sc/28EGlzizA2xztSenWyeehqQf2IFXzy8RMDIQ9UTyJJJe2DWNXLPd
F6gNi8qDvmJcvTtyyJOynV9auCai6mpJUq9Tgyo8Vd9cUJVzXtwjdTfIwvr8d36M
cjmSGHxf9ohugUe0yJfw3MD3L0Og0QidWp+4Uw1uzL/SaliEdSvnB0pWl6LRYr5L
zHTcjPivkW7ADDBfIwXGgt+mTjcGIzvtjTU6enG2mAMrEFWgJoIqw6nZUyXMgmHL
RvGy/1hIU1SzEHhSOtHFfu2G3tqMNzQvPCB9C8JkJfCAUYwQN/on/C/yjLm6BanY
BkEupJ2AmiOzch2aOc3qOv/xCtrxmH2GI/7riAmuo2PHUe2adAuR2OUz7RFnW0yi
Dz9ZMRmLx3th+JsmH6vM4NDHWx2j2psl31L1zkc4KxI41+Xj2U4XUki6i6/JutA7
tED9/QcB65TrWv/klgUoR0+EB2tgi1qMHj8dMqEfrM4hL3TNflknHEJs7XwXHxBp
pnfvv3K6yL5P6U47h89Z4GGdzsfFB7qjFOobW5q9CeAkhffKWa2qJh/Kb4oonjO0
QD1tiND32ifIIAF8ifjD
=Nxae
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xD8407950.asc
Type: application/pgp-keys
Size: 9706 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20110921/54fdada8/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xD8407950.asc.sig
Type: application/pgp-signature
Size: 543 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20110921/54fdada8/attachment-0002.sig>