implicit renaming of packages containing libraries

["Peter A. Bigot" <pab@pabigot.com>]

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