[OE-core] implicit renaming of packages containing libraries
Peter A. Bigot
pab at pabigot.com
Sat Aug 16 14:09:56 UTC 2014
Many recipes split out the pieces they build into separate packages; I'm
looking at meta-oe/recipes-support/lmsensors/lmsensors_3.3.5.bb as an
example. Generally that's done with directives like:
# libsensors files
FILES_${PN}-libsensors = "${libdir}/libsensors.so.*
${sysconfdir}/sensors3.conf ${sysconfdir}/sensors.d"
FILES_${PN}-libsensors-dbg = "${libdir}/.debug ${prefix}/src/debug"
FILES_${PN}-libsensors-dev = "${libdir}/libsensors.so ${includedir}"
FILES_${PN}-libsensors-staticdev = "${libdir}/libsensors.a"
FILES_${PN}-libsensors-doc = "${mandir}/man3"
Although the initial package split follows the names specified in the
recipe, something (probably INHERIT_DISTRO="debian") is inserting a call
to debian_package_name_hook so what actually gets written is:
libsensors-dbg-3.3.5-r0.0.cortexa8hf_vfp_neon.rpm
libsensors-dev-3.3.5-r0.0.cortexa8hf_vfp_neon.rpm
libsensors-doc-3.3.5-r0.0.cortexa8hf_vfp_neon.rpm
libsensors-staticdev-3.3.5-r0.0.cortexa8hf_vfp_neon.rpm
libsensors4-3.3.5-r0.0.cortexa8hf_vfp_neon.rpm
lmsensors-dbg-3.3.5-r0.0.cortexa8hf_vfp_neon.rpm
lmsensors-dev-3.3.5-r0.0.cortexa8hf_vfp_neon.rpm
...
I expected the packages to be what the recipe specified. An undesirable
effect of the rename is that when I use "smart search lmsensors" the
libraries in lmsensors that I was looking for don't show up because the
lmsensors- prefix was removed from the RPM.
Is this intentional? Is it documented somewhere? I wouldn't be
terribly upset if lmsensors-libsensors got renamed to
lmsensors-libsensors4 because Debian policy expects the SO number to be
part of the name, but it's weird to have the owning package stripped off
like this.
Peter
More information about the Openembedded-core
mailing list