[V2,02/25] shlibpackaging.bbclass: create common class

Submitted by Saul Wold on July 13, 2011, 7:33 a.m. | Patch ID: 7473


Message ID 79c857d74346635be316e2bf42dc8d4224095da2.1310541680.git.sgw@linux.intel.com
State New, archived
Headers show

Commit Message

Saul Wold July 13, 2011, 7:33 a.m.
This class is for packages that do not work with debian library naming

Signed-off-by: Saul Wold <sgw@linux.intel.com>
 meta/classes/shlibpackaging.bbclass |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)
 create mode 100644 meta/classes/shlibpackaging.bbclass

Patch hide | download patch | download mbox

diff --git a/meta/classes/shlibpackaging.bbclass b/meta/classes/shlibpackaging.bbclass
new file mode 100644
index 0000000..3406793
--- /dev/null
+++ b/meta/classes/shlibpackaging.bbclass
@@ -0,0 +1,9 @@ 
+# This bbclass it a common case for lib${PN} shared libraries
+SUMMARY_lib${PN} ?= "${SUMMARY} - Shared Libraries"
+DESCRIPTION_lib${PN} ?= "${DESCRIPTION} This package contains the shared libraries"
+PACKAGES =+ "lib${PN}"
+FILES_lib${PN} = "${libdir}/*${SOLIBS} ${base_libdir}/*${SOLIBS}"
+RDEPENDS_lib${PN} = "${PN}"


Phil Blundell July 13, 2011, 9:17 a.m.
On Wed, 2011-07-13 at 00:33 -0700, Saul Wold wrote:
> +RDEPENDS_lib${PN} = "${PN}"

Why do we want lib${PN} to have a hard dependency on ${PN}?  This seems
somewhat backwards to me.  

Also, if ${PN} is the one with the binaries then it will get an
auto-generated dependency back to lib${PN} anyway and it looks like this
will cause a dependency loop.

Also also, if it really is correct for lib${PN} to RDEPEND on ${PN}
then, in the general case, it probably ought to be a precisely versioned
dependency to guarantee correctness.  Individual recipes can relax that
if they want to.