[OE-core] [PATCH] gtk-icon-cache.bbclass: Fix multiple rebuilds of the icon cache on first boot

[Richard Purdie]

On Mon, 2012-03-26 at 09:39 +0200, Andreas Müller wrote:
> On Sat, Mar 24, 2012 at 12:37 AM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
> > On Fri, 2012-03-23 at 23:46 +0100, Andreas Müller wrote:
> >> On Fri, Mar 23, 2012 at 1:12 PM, Richard Purdie
> >> <richard.purdie at linuxfoundation.org> wrote:
> >> > On Thu, 2012-03-22 at 20:15 +0100, Andreas Müller wrote:
> >> >> * Before this patch every inheritance of this class rebuilt the full icon cache at the first boot.
> >> >> * With this patch the icon cache will only be build once at the first boot and on pkg installations that require it.
> >> >> * This patch reduces the time needed for the first boot from 96 minutes to 5 minutes on the test machine.
> >> >> * Build-tested incremental (BB_SIGNATURE_HANDLER = "OEBasicHash") & from scratch
> >> >> * Run-tested with systemd and opkg
> >> >>
> >> >> Signed-off-by: Samuel Stirtzel <s.stirtzel at googlemail.com>
> >> >> Signed-off-by: Andreas Müller <schnitzeltony at googlemail.com>
> >> >> ---
> >> >>  meta/classes/gtk-icon-cache.bbclass                |   19 +++++++++-------
> >> >>  .../gtk+/gtk-update-icon-cache-runonce.bb          |   23 ++++++++++++++++++++
> >> >>  .../gtk-update-icon-cache-runonce.in               |   16 +++++++++++++
> >> >>  3 files changed, 50 insertions(+), 8 deletions(-)
> >> >>  create mode 100644 meta/recipes-gnome/gtk+/gtk-update-icon-cache-runonce.bb
> >> >>  create mode 100644 meta/recipes-gnome/gtk+/gtk-update-icon-cache-runonce/gtk-update-icon-cache-runonce.in
> >> >>
> >> >> diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-icon-cache.bbclass
> >> >> index 60e3401..b48aabe 100644
> >> >> --- a/meta/classes/gtk-icon-cache.bbclass
> >> >> +++ b/meta/classes/gtk-icon-cache.bbclass
> >> >> @@ -9,14 +9,16 @@ if [ "x$D" != "x" ]; then
> >> >>          exit 1
> >> >>  fi
> >> >>
> >> >> -# Update the pixbuf loaders in case they haven't been registered yet
> >> >> -GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders gdk-pixbuf-query-loaders --update-cache
> >> >> -
> >> >> -for icondir in /usr/share/icons/* ; do
> >> >> -    if [ -d $icondir ] ; then
> >> >> -        gtk-update-icon-cache -fqt  $icondir
> >> >> -    fi
> >> >> -done
> >> >> +# do not execute in case a final run-once is waiting
> >> >> +if [ ! -e ${sysconfdir}/init.d/gtk-update-icon-cache-runonce ]; then
> >> >> +    # Update the pixbuf loaders in case they haven't been registered yet
> >> >> +    GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders gdk-pixbuf-query-loaders --update-cache
> >> >> +    for icondir in /usr/share/icons/* ; do
> >> >> +        if [ -d $icondir ] ; then
> >> >> +            gtk-update-icon-cache -fqt  $icondir
> >> >> +        fi
> >> >> +    done
> >> >> +fi
> >> >
> >> >
> >> > Can't we just reduce this to adding a "touch
> >> > ${sysconfdir}/init.d/gtk-update-icon-cache-runonce" to the above code
> >> > and then clear that file at boot time?
> >> >
> >> Maybe it's a misunderstanding on my side but how shall an empty file
> >> cover the three tasks during 1st boot:
> >>
> >> 1. Preventing all postints of running gtk-update-icon-cache by existing
> >> 2. Running gtk-update-icon-cache ( after postinsts )
> >> 3. Deleting itself and thereby avoid running during subsequent boots
> >> and ensuring that packages which are installed later do run
> >> gtk-update-icon-cache.
> >
> > The first time something tries this it creates the "lock".
> > Any subsequent postinstall sees the "lock" and knows not to run.
> >
> > There are two problems:
> >
> > a) Knowing these are postinstalls at first boot and not package installs
> > b) Deleting the unused "lock" files afterwards
> >
> > You'd therefore probably have to add something to the postinstalls core
> > which:
> >
> > a) Creates some file during final rootfs postinstalls on first boot
> > b) Clears some set of files after first boot.
> Isn't this exactly what we are doing?
> >
> > I don't see a major issue with doing either of these two things though
> > and it would simplify your patch whilst also allowing other similar
> > cases to work in a similar way.
> >
> We presented a working solution fixing an issue existing for long time
> and don't see that this suggestion gives major enhancements. Feel free
> to present a different solution.

Right, what I'm trying to figure out is whether we can simplify that
implementation a little so we don't need a new recipe, dependencies and
a new init script. There is nothing wrong with that solution but I think
its possible to simplify things a little.

My worry is whether the simplifications I have in mind will work in the
systemd world :/.

Cheers,

Richard