[OE-core] [PATCH 3/5] package_rpm: export the native directory to the postinst scriptlets

[Mark Hatle]

On 8/4/12 3:59 AM, Laurentiu Palcu wrote:
>
>
> On 08/04/2012 10:46 AM, Laurentiu Palcu wrote:
>>
>>
>> On 08/03/2012 11:25 PM, Mark Hatle wrote:
>>> On 8/3/12 3:19 PM, Laurentiu Palcu wrote:
>>>> Some postinst scriptlets test for the existence of certain files but
>>>> have the paths hardcoded to the target's rootfs. This patch will allow
>>>> us to run postinst scriptlets at do_rootfs time by calling native
>>>> binaries.
>>>>
>>>> Signed-off-by: Laurentiu Palcu <laurentiu.palcu at intel.com>
>>>> ---
>>>>    meta/classes/package_rpm.bbclass |    1 +
>>>>    1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
>>>> index 50e9b31..113b19c 100644
>>>> --- a/meta/classes/package_rpm.bbclass
>>>> +++ b/meta/classes/package_rpm.bbclass
>>>> @@ -443,6 +443,7 @@ export D="${target_rootfs}"
>>>>    export OFFLINE_ROOT="\$D"
>>>>    export IPKG_OFFLINE_ROOT="\$D"
>>>>    export OPKG_OFFLINE_ROOT="\$D"
>>>> +export NATIVE_DIR="${STAGING_DIR_NATIVE}"
>>>
>>> Why is this needed?  Normally the host items run from the path (and should know
>>> how to access any related files they need), and ${D} points to the target rootfs
>>> directory for things needing full paths.
>> Hmm, I think you're perfectly right... I needed it because the
>> gdk-pixbuf postinst scriplet tested the existence of
>> gtk-update-icon-cache binary but, now that you mentioned it, I realized
>> it might work without it. Test the existence of the binary on target
>> rootfs but run the native one from PATH.
> However, I just remembered that the rpm packages are not installed in
> dependency order... So, there might be packages, that need
> gtk-update-icon-cache, installed before libgtk+ is installed. In this
> case, the postinst scriptlets that test the existence of the binary on
> the target rootfs will fail at do_roofts time... Unless a solution is
> found to install the rpm packages in dependency order. BTW, is this
> planned to be fixed?

Install order vs scriptlet order are different.  The package dependencies 
indicate when the transaction is complete all dependent packages will be 
installed.  The scriptlets can be delayed or run during the install process. 
I'm not sure what controls when they run, but that is a separate action from the 
actual install process itself.

I have not has the time to investigate the control of the scriptlets, but it's 
on my list.

Back to the issue at hand though.  Two solutions, the first is simply run the 
program and if it fails, ignore the failure or "stage" it for later (or fail), 
whichever is appropriate.  The only thing that checking for the binary 
accomplishes is knowing if it might fail or not, it's likely just as easy to 
check for a failure trying to run the binary.

For the cross install case, you can check for the existence of the ${D} 
variable.  If it doesn't exist then you are on the target, and you can do 
whatever checks are necessary -- but on the host side you will have to assume 
the binary exists and is available [based on the recipe requirements.]

--Mark

> Laurentiu
>>
>> Thanks for the tip,
>> Laurentiu
>>>
>>> --Mark
>>>
>>>>
>>>>    \$2 \$1/\$3 \$4
>>>>    if [ \$? -ne 0 ]; then
>>>>
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core at lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>