| Submitter | Saul Wold |
|---|---|
| Date | July 11, 2011, 11:13 p.m. |
| Message ID | <1122cff5b635c23b36bc76ad58a088f522ac21a5.1310425837.git.sgw@linux.intel.com> |
| Download | mbox | patch |
| Permalink | /patch/7357/ |
| State | New, archived |
| Headers | show |
Comments
Op 12 jul 2011, om 01:13 heeft Saul Wold het volgende geschreven: > This class is for packages that do not work with debian library naming If you put a single library in a package it *will* do shlib renaming. > > Signed-off-by: Saul Wold <sgw@linux.intel.com> > --- > meta/classes/shared_lib.bbclass | 9 +++++++++ Can we name is sharedlib.bbclass or better shlibpackaging.bbclass? > 1 files changed, 9 insertions(+), 0 deletions(-) > create mode 100644 meta/classes/shared_lib.bbclass > > diff --git a/meta/classes/shared_lib.bbclass b/meta/classes/shared_lib.bbclass > new file mode 100644 > index 0000000..4237c8c > --- /dev/null > +++ b/meta/classes/shared_lib.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}" I think you want =+ there > +FILES_lib${PN} = "${libdir}/*${SOLIBS} ${base_libdir}/*${SOLIBS}" > +RDEPENDS_lib${PN} = "${PN}" > -- > 1.7.3.4 > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Mon, 2011-07-11 at 16:13 -0700, Saul Wold wrote:
> This class is for packages that do not work with debian library naming
I tend to feel that most of those packages should be fixed so that they
do. If they aren't currently getting renamed then it usually means that
they include too much (i.e. both binaries and libraries, or multiple
libraries) and should be split up so that this doesn't happen.
For the rare cases where you really do want to put multiple SOs in a
single output package you can use LEAD_SONAME, but this is virtually
never the right thing to do.
p.
On Tue, 2011-07-12 at 10:11 +0100, Phil Blundell wrote: > On Mon, 2011-07-11 at 16:13 -0700, Saul Wold wrote: > > This class is for packages that do not work with debian library naming > > I tend to feel that most of those packages should be fixed so that they > do. If they aren't currently getting renamed then it usually means that > they include too much (i.e. both binaries and libraries, or multiple > libraries) and should be split up so that this doesn't happen. Actually, looking at the patch more carefully I guess this does basically address the first case above (binaries and libraries). But it looks like it will result in the slightly confusing situation where the libraries go into lib${PN} but the corresponding headers are in ${PN}-dev. p.
On 07/12/2011 02:13 AM, Phil Blundell wrote: > On Tue, 2011-07-12 at 10:11 +0100, Phil Blundell wrote: >> On Mon, 2011-07-11 at 16:13 -0700, Saul Wold wrote: >>> This class is for packages that do not work with debian library naming >> >> I tend to feel that most of those packages should be fixed so that they >> do. If they aren't currently getting renamed then it usually means that >> they include too much (i.e. both binaries and libraries, or multiple >> libraries) and should be split up so that this doesn't happen. > > Actually, looking at the patch more carefully I guess this does > basically address the first case above (binaries and libraries). But it > looks like it will result in the slightly confusing situation where the > libraries go into lib${PN} but the corresponding headers are in > ${PN}-dev. > Correct, this is trying to address the existing cases that have both binaries and libraries, I guess the other way to do this would be for those 5 or so packages to use "lib_packaging" and which renames the binary packages ${PN}-bin and the libraries then get auto renamed via debian renaming rules. This is kind of the inverse of lib_packaging.bbclass, binaries go in ${PN} and libraries need to be placed into the named lib${PN}. As for headers and debug, they go in the ${PN}-[dev,dbg] packagse I can go with Koen's name of shlibpackaging.bbclass Sau! > p. > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >
Patch
diff --git a/meta/classes/shared_lib.bbclass b/meta/classes/shared_lib.bbclass new file mode 100644 index 0000000..4237c8c --- /dev/null +++ b/meta/classes/shared_lib.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}"
This class is for packages that do not work with debian library naming Signed-off-by: Saul Wold <sgw@linux.intel.com> --- meta/classes/shared_lib.bbclass | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) create mode 100644 meta/classes/shared_lib.bbclass