[OE-core] [RFC 0/7] Postinstall improvements

[Andreas Müller]

On Wed, Sep 26, 2012 at 9:41 AM, Andreas Müller
<schnitzeltony at googlemail.com> wrote:
> On Wed, Sep 26, 2012 at 9:09 AM, Laurentiu Palcu
> <laurentiu.palcu at intel.com> wrote:
>>
>>
>> On 09/20/2012 07:12 PM, Andreas Müller wrote:
>>> On Thu, Sep 20, 2012 at 5:38 PM, Andreas Müller
>>> <schnitzeltony at googlemail.com> wrote:
>>>> On Wed, Sep 19, 2012 at 5:33 PM, Laurentiu Palcu
>>>> <laurentiu.palcu at intel.com> wrote:
>>>>>
>>>>>
>>>>> On 09/19/2012 04:41 PM, Andreas Müller wrote:
>>>>>> On Wed, Sep 19, 2012 at 1:49 PM, Laurentiu Palcu
>>>>>> <laurentiu.palcu at intel.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> It's been quite a long time since I sent the first version of postinstall
>>>>>>> improvements which, after some debate, we decided it needed run-once
>>>>>>> support of postinst scriptlets on host. This patcheset (RFC actually) adds
>>>>>>> that.
>>>>>>>
>>>>>>> So, in order to achieve this goal I took advantage of
>>>>>>> ROOTFS_POSTPROCESS_COMMAND variable. Basically, if running some postinst
>>>>>>> scriptlets is time consuming (even on host) and execute repeatedly,
>>>>>>> then we can postpone the running and run the scriplet just once. The idea is
>>>>>>> to put the scriptlet in the ${WORKDIR}/intercept_scripts directory. When the
>>>>>>> ROOTFS_POSTPROCESS_COMMAND is executed, it will pick up all the scripts in
>>>>>>> this directory and execute them.
>>>>>>>
>>>>>>> This actual patchset does the above for the gtk icon cache generation which
>>>>>>> takes a very long time to run on target and even on some hosts.
>>>>>>>
>>>>>>> The people willing to give this patchset a test, are most than welcome. Also,
>>>>>>> please feel free to review.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Laurentiu
>>>>>>>
>>>>>> Thanks for taking care. I will give it a test tonight and hope to have
>>>>>> results tomorrow.
>>>>> It would be great if you could give it a try and let me know your results.
>>>>>
>>>> I removed gtk-native append in meta-oe, build from scratch and tested
>>>> the image. No issues so far - seems you have done a great job -
>>>> Thanks!
>>>>
>>> Aargh I really would like to consider this done but I found suspicious
>>> when browsing on the machine with the new image (hicolor- and
>>> gnome-icon-theme installed):
>>>
>>> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
>>> * /usr/share/icons/hicolor/icon-theme.cache is there but it has the
>>> date of 01.01.2000 (have no rtc backup on the machine). I would expect
>>> this file to have build host's date.
>>>
>>> So I checked the contents on the build machine in image's rootfs:
>>>
>>> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
>>> * /usr/share/icons/hicolor/icon-theme.cache is there but has only
>>> 64,5KB (the version on the machine is 2,3MB!!).
>> Did you have any chance to debug the issue on your setup? I tried to
>> replicate your environment but I failed. Lots of build errors, so I gave
>> up. It would have taken me more time to make your setup work than
>> debugging the real problem.
>>
>> Another alternative would be for you to prepare a tarball with all the
>> repos and configs that you use and put it somewhere where I can take it.
>> It would be easier for me to directly start debugging your issue.
>>
> Sorry but I am occupied by other issues at the moment. Hope to find
> time at the weekend to add some debug messages to see what's going on.
>
Oh it's that simple: run_intercept_scriptlets is not called here (I
don't know what caused 'mini hicolor-icon-theme's cache)! You can
reproduce that e.g. by enabling buildhistory.

I simply replaced in image.bbclass

ROOTFS_POSTPROCESS_COMMAND ?= "run_intercept_scriptlets"
by
ROOTFS_POSTPROCESS_COMMAND =+ "run_intercept_scriptlets;"

an now see larger caches for all my icon themes. But the sizes are
still different from those mentioned above. Will run-test tomorrow.

Andreas