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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
