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

[Andreas Müller]

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.

Andreas