libpython2
Hi,
bitbake complains:
"NOTE: multiple providers are available for runtime libpython2 (python, python-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match libpython2"
That's because I'm building a recipe for a binary that RDEPENDS_${PN} on libpython2. So I added PREFERRED_PROVIDER_libpython2 = "python" to my disto.conf, but the warning cited above persists.
python_2.7.2.bb contains:
PACKAGES =+ "lib${BPN}2"
...
BBCLASSEXTEND = "nativesdk"
Shouldn't it rather create libpython2 and libpython2-nativesdk or something similar?
What could be the reason for the warning to persist?
Regards,
Andreas
Quoted 10 lines · Andreas Oberritter
"NOTE: multiple providers are available for runtime libpython2 (python, python-nativesdk)
NOTE: consider defining aPREFERRED_PROVIDERentry to match libpython2"That's because I'm building a recipe for a binary that RDEPENDS_${PN} on libpython2. So I added
PREFERRED_PROVIDER_libpython2= "python" to my disto.conf, but the warning cited above persists.python_2.7.2.bb contains:
Quoted 8 lines
PACKAGES =+ "lib${BPN}2"
...
BBCLASSEXTEND = "nativesdk"Shouldn't it rather create libpython2 and libpython2-nativesdk or something similar?
What could be the reason for the warning to persist?
Because PREFERRED_PROVIDER_<some runtime provide> = "some recipe" is invalid. PREFERRED_PROVIDER_ only ever operates against build time dependencies. The runtime are worked out based on that. If you were to set something like PREFERRED_PROVIDER_python = "python", it would probably shut the warning up, as it would see that a preference exists on a recipe that provides one of the runtime packages, and would therefore know which to use. Having to rely on this sort of implicit behavior rather than having a means of explicitly specifying runtime preferences is a flaw in bitbake, in my opinion.
Signature · 1 line
Christopher Larson
Quoted 21 lines · Chris Larson
Quoted 10 lines · Andreas Oberritter
"NOTE: multiple providers are available for runtime libpython2 (python, python-nativesdk)
NOTE: consider defining aPREFERRED_PROVIDERentry to match libpython2"That's because I'm building a recipe for a binary that RDEPENDS_${PN} on libpython2. So I added
PREFERRED_PROVIDER_libpython2= "python" to my disto.conf, but the warning cited above persists.python_2.7.2.bb contains:
Quoted 8 lines
PACKAGES =+ "lib${BPN}2"
...
BBCLASSEXTEND = "nativesdk"Shouldn't it rather create libpython2 and libpython2-nativesdk or something similar?
What could be the reason for the warning to persist?
Quoted 9 lines
Because PREFERRED_PROVIDER_<some runtime provide> = "some recipe" is invalid.
PREFERRED_PROVIDER_only ever operates against build time dependencies. The runtime are worked out based on that. If you were to set something likePREFERRED_PROVIDER_python= "python", it would probably shut the warning up, as it would see that a preference exists on a recipe that provides one of the runtime packages, and would therefore know which to use. Having to rely on this sort of implicit behavior rather than having a means of explicitly specifying runtime preferences is a flaw in bitbake, in my opinion.
python-nativesdk should simply not be providing libpython2...
Cheers,
Richard
Quoted 14 lines · Andreas Oberritter
Hi,
bitbake complains:
"NOTE: multiple providers are available for runtime libpython2 (python, python-nativesdk)
NOTE: consider defining aPREFERRED_PROVIDERentry to match libpython2"That's because I'm building a recipe for a binary that RDEPENDS_${PN} on libpython2. So I added
PREFERRED_PROVIDER_libpython2= "python" to my disto.conf, but the warning cited above persists.python_2.7.2.bb contains:
Quoted 8 lines
PACKAGES =+ "lib${BPN}2"
...
BBCLASSEXTEND = "nativesdk"Shouldn't it rather create libpython2 and libpython2-nativesdk or something similar?
What could be the reason for the warning to persist?
python-nativesdk should not be providing libpython2. There is a bug in the packaging somewhere. This usually results in needing to add the PKGSUFFIX mess. I want to get rid of that entirely and switch to the multilib way of handling this with a prefix but it didn't happen in time for 1.2 :(.
Cheers,
Richard