Skip to contentSkip to conversation

implicit renaming of packages containing libraries

DISCUSSION Peter A. Bigot 2 participants 2 messages Aug 16, 2014 – Aug 27, 2014

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw
Quoted 4 lines · Peter A. Bigot

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.

Yes, it's intentional.
http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-debian
is the documentation, it's quite sparse and could be expanded but does cover the basics.

Some recipes - eg mesa - override the renaming because they want the origin recipe to be part of the name.

(FWIW, Debian has a source package lm-sensors but the library is libsensors4)

Ross