Patchwork pango: have postinstalls run at do_rootfs time

login
register
mail settings
Submitter Laurentiu Palcu
Date Dec. 19, 2012, 4:03 p.m.
Message ID <1355933032-25392-1-git-send-email-laurentiu.palcu@intel.com>
Download mbox | patch
Permalink /patch/41375/
State Accepted
Commit 75334cbee1f064b38f167269917e333989802e7d
Headers show

Comments

Laurentiu Palcu - Dec. 19, 2012, 4:03 p.m.
Since pango-native is built anyway and all the modules are in the native
sysroot, create the cache file by scanning those files instead of the
target files. The latter will fail because the shared objects wouldn't
be from the same ELF class.

[YOCTO #3600]

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
---
 meta/recipes-graphics/pango/pango.inc |   26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)
Laurentiu Palcu - Dec. 20, 2012, 9:55 a.m.
On Wed, Dec 19, 2012 at 06:03:52PM +0200, Laurentiu Palcu wrote:

Ignore this patch, it is the same as the previous one.... I really have
no idea why this mail appeared on the mailing list, hours after I sent
the original patch. Weird... Probably a 'git send-mail' issue.

Thanks,
Laurentiu

> Since pango-native is built anyway and all the modules are in the native
> sysroot, create the cache file by scanning those files instead of the
> target files. The latter will fail because the shared objects wouldn't
> be from the same ELF class.
> 
> [YOCTO #3600]
> 
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
> ---
>  meta/recipes-graphics/pango/pango.inc |   26 ++++++++++++++++++++++----
>  1 file changed, 22 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/recipes-graphics/pango/pango.inc b/meta/recipes-graphics/pango/pango.inc
> index 839c00d..81c2a7e 100644
> --- a/meta/recipes-graphics/pango/pango.inc
> +++ b/meta/recipes-graphics/pango/pango.inc
> @@ -10,7 +10,7 @@ SECTION = "libs"
>  LICENSE = "LGPLv2.0+"
>  
>  X11DEPENDS = "virtual/libx11 libxft"
> -DEPENDS = "glib-2.0 fontconfig freetype zlib virtual/libiconv cairo elfutils"
> +DEPENDS = "glib-2.0 fontconfig freetype zlib virtual/libiconv cairo elfutils pango-native"
>  
>  PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
>  PACKAGECONFIG[x11] = "--with-x,--without-x,${X11DEPENDS}"
> @@ -44,13 +44,31 @@ LEAD_SONAME = "libpango-1.0*"
>  LIBV = "1.6.0"
>  
>  postinst_prologue() {
> +if ! [ -e $D${sysconfdir}/pango ] ; then
> +	mkdir -p $D${sysconfdir}/pango
> +fi
> +
>  if [ "x$D" != "x" ]; then
> -  exit 1
> +pango-querymodules $(ls -d -1 $D${libdir}/pango/${LIBV}/modules/*.so|\
> +    sed -e "s:$D:$NATIVE_ROOT:g") >\
> +    $D${sysconfdir}/pango/${MLPREFIX}pango.modules \
> +    2>$D${sysconfdir}/pango/${MLPREFIX}pango.err
> +
> +# pango-querymodules always returns 0, so we need to check if pango.err has
> +# anything in it
> +if [ -s $D${sysconfdir}/pango/${MLPREFIX}pango.err ]; then
> +    rm $D${sysconfdir}/pango/${MLPREFIX}pango.err
> +    exit 1
>  fi
>  
> -if ! [ -e $D${sysconfdir}/pango ] ; then
> -	mkdir -p $D${sysconfdir}/pango
> +sed -i -e "s:$NATIVE_ROOT::g" $D${sysconfdir}/pango/${MLPREFIX}pango.modules
> +
> +# remove the empty pango.err
> +rm $D${sysconfdir}/pango/${MLPREFIX}pango.err
> +
> +exit 0
>  fi
> +
>  }
>  
>  do_install_append () {
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - Dec. 20, 2012, 3:21 p.m.
On Wed, 2012-12-19 at 18:03 +0200, Laurentiu Palcu wrote:
> Since pango-native is built anyway and all the modules are in the native
> sysroot, create the cache file by scanning those files instead of the
> target files. The latter will fail because the shared objects wouldn't
> be from the same ELF class.

Is it guaranteed that the native build will have the same set of
modules?  It seems to me that it would be safer to scan the target ones
under qemu as you did for gtk-immodules.

p.
Laurentiu Palcu - Dec. 20, 2012, 3:47 p.m.
On 12/20/2012 05:21 PM, Phil Blundell wrote:
> On Wed, 2012-12-19 at 18:03 +0200, Laurentiu Palcu wrote:
>> Since pango-native is built anyway and all the modules are in the native
>> sysroot, create the cache file by scanning those files instead of the
>> target files. The latter will fail because the shared objects wouldn't
>> be from the same ELF class.
> 
> Is it guaranteed that the native build will have the same set of
> modules?  It seems to me that it would be safer to scan the target ones
> under qemu as you did for gtk-immodules.
AFAIK pango-native builds all modules. I suppose I could also do it as I
did it for matchbox-keyboard package but I'd always prefer to avoid qemu
overhead whenever we can do it entirely natively.

Thanks,
Laurentiu
> 
> p.
> 
>
Ross Burton - Dec. 20, 2012, 3:59 p.m.
On 20 December 2012 15:21, Phil Blundell <philb@gnu.org> wrote:
> On Wed, 2012-12-19 at 18:03 +0200, Laurentiu Palcu wrote:
>> Since pango-native is built anyway and all the modules are in the native
>> sysroot, create the cache file by scanning those files instead of the
>> target files. The latter will fail because the shared objects wouldn't
>> be from the same ELF class.
>
> Is it guaranteed that the native build will have the same set of
> modules?  It seems to me that it would be safer to scan the target ones
> under qemu as you did for gtk-immodules.

I suspected there was no such real thing as an out-of-tree Pango
module, but I was wrong (http://graphite.sil.org/).

Digging quickly into the Debian packaging, they generate the modules
list at build time (not in a postinst) by running pango-querymodules
over the directories they just built, filtering the paths (this
happens in dh_pangomodules).  They also generate a modules list file
per package and ship it, and pango reads the multiple files.  I'm not
sure if this is upstream behaviour or a Debian-specific patch.

Ross
Laurentiu Palcu - Dec. 20, 2012, 4:21 p.m.
On 12/20/2012 05:59 PM, Burton, Ross wrote:
> On 20 December 2012 15:21, Phil Blundell <philb@gnu.org> wrote:
>> On Wed, 2012-12-19 at 18:03 +0200, Laurentiu Palcu wrote:
>>> Since pango-native is built anyway and all the modules are in the native
>>> sysroot, create the cache file by scanning those files instead of the
>>> target files. The latter will fail because the shared objects wouldn't
>>> be from the same ELF class.
>>
>> Is it guaranteed that the native build will have the same set of
>> modules?  It seems to me that it would be safer to scan the target ones
>> under qemu as you did for gtk-immodules.
> 
> I suspected there was no such real thing as an out-of-tree Pango
> module, but I was wrong (http://graphite.sil.org/).
But, in this case, we could use the qemu method only for the graphite
package postinstall... We don't have to use it for pango too.

> 
> Digging quickly into the Debian packaging, they generate the modules
> list at build time (not in a postinst) by running pango-querymodules
> over the directories they just built, filtering the paths (this
> happens in dh_pangomodules).  They also generate a modules list file
> per package and ship it, and pango reads the multiple files.  I'm not
> sure if this is upstream behaviour or a Debian-specific patch.
How do they handle the cross-compiling issue? They cannot run the native
pango-querymodules on a cross-compiled shared object. It will fail.

Thanks,
Laurentiu
> 
> Ross
>
Ross Burton - Dec. 20, 2012, 4:29 p.m.
On 20 December 2012 16:21, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote:
> How do they handle the cross-compiling issue? They cannot run the native
> pango-querymodules on a cross-compiled shared object. It will fail.

Sure, they don't have that problem.  But for us, any package that
ships pango modules could use qemu to generate it's modules files.

It was mainly an interesting comparison of packaging strategy.

Ross
Otavio Salvador - Dec. 20, 2012, 4:40 p.m.
On Thu, Dec 20, 2012 at 2:29 PM, Burton, Ross <ross.burton@intel.com> wrote:
> On 20 December 2012 16:21, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote:
>> How do they handle the cross-compiling issue? They cannot run the native
>> pango-querymodules on a cross-compiled shared object. It will fail.
>
> Sure, they don't have that problem.  But for us, any package that
> ships pango modules could use qemu to generate it's modules files.
>
> It was mainly an interesting comparison of packaging strategy.

And the speed boost in first boot and the possibility to use read-only
rootfs is worth the qemu overhead I think :-)

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Patch

diff --git a/meta/recipes-graphics/pango/pango.inc b/meta/recipes-graphics/pango/pango.inc
index 839c00d..81c2a7e 100644
--- a/meta/recipes-graphics/pango/pango.inc
+++ b/meta/recipes-graphics/pango/pango.inc
@@ -10,7 +10,7 @@  SECTION = "libs"
 LICENSE = "LGPLv2.0+"
 
 X11DEPENDS = "virtual/libx11 libxft"
-DEPENDS = "glib-2.0 fontconfig freetype zlib virtual/libiconv cairo elfutils"
+DEPENDS = "glib-2.0 fontconfig freetype zlib virtual/libiconv cairo elfutils pango-native"
 
 PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
 PACKAGECONFIG[x11] = "--with-x,--without-x,${X11DEPENDS}"
@@ -44,13 +44,31 @@  LEAD_SONAME = "libpango-1.0*"
 LIBV = "1.6.0"
 
 postinst_prologue() {
+if ! [ -e $D${sysconfdir}/pango ] ; then
+	mkdir -p $D${sysconfdir}/pango
+fi
+
 if [ "x$D" != "x" ]; then
-  exit 1
+pango-querymodules $(ls -d -1 $D${libdir}/pango/${LIBV}/modules/*.so|\
+    sed -e "s:$D:$NATIVE_ROOT:g") >\
+    $D${sysconfdir}/pango/${MLPREFIX}pango.modules \
+    2>$D${sysconfdir}/pango/${MLPREFIX}pango.err
+
+# pango-querymodules always returns 0, so we need to check if pango.err has
+# anything in it
+if [ -s $D${sysconfdir}/pango/${MLPREFIX}pango.err ]; then
+    rm $D${sysconfdir}/pango/${MLPREFIX}pango.err
+    exit 1
 fi
 
-if ! [ -e $D${sysconfdir}/pango ] ; then
-	mkdir -p $D${sysconfdir}/pango
+sed -i -e "s:$NATIVE_ROOT::g" $D${sysconfdir}/pango/${MLPREFIX}pango.modules
+
+# remove the empty pango.err
+rm $D${sysconfdir}/pango/${MLPREFIX}pango.err
+
+exit 0
 fi
+
 }
 
 do_install_append () {