[OE-core] Prelink problem

[Andrej Valek]

Hi all

Do we found some solution? As a workaround could be just add dependency
to prelink native into rootfs if the command is really required.

Regards,
Andrej

On 1/8/19 10:46 PM, Richard Purdie wrote:
> On Tue, 2019-01-08 at 14:50 -0600, Mark Hatle wrote:
>> On 1/8/19 2:37 PM, Burton, Ross wrote:
>>> On Tue, 8 Jan 2019 at 20:15, Mark Hatle <mark.hatle at windriver.com>
>>> wrote:
>>>>> No idea why the opkg rootfs code is doing prelink operations
>>>>> when RPM
>>>>> or dpkg don't.   CCing Mark who may have an idea here.  I
>>>>> thought the
>>>>> autobuilder exerised multilib-on-opkg, but maybe not.
>>>>
>>>> They all should be doing prelink operations.  The operation
>>>> SHOULD be
>>>> generically implemented as part of the image-prelink class, which
>>>> is where I
>>>> would have expected that copy to exist.
>>>>
>>>> If any of the package types of specifically doing something, that
>>>> sounds
>>>> broken...  but the generic ones (last I looked) said to copy in
>>>> the config file
>>>> [if it didn't exist], run prelink, remove the file [if it wasn't
>>>> there to start
>>>> with].
>>>
>>> Note that it's part of the incremental code, so needs to be in the
>>> rootfs code directly I suspect. Frankly I'd love to see incremental
>>> images removed.  It makes promises it can't keep (the moment a
>>> rootfs
>>> postprocess command is used, all bets are off) and massively
>>> complicates things.
>>
>> We assume the post process command is what an 'admin' would do.  So
>> the various
>> package managers should be able to deal with it in most
>> cases.  (Note, obviously
>> it's more freeform, but I wouldn't expect everything to work in you
>> removed a
>> large part of the filesystem for instance.)
>>
>> As for prelink, I'm surprised this is in the incremental code.  I'm
>> not sure why
>> it would be necessary unless the incremental work wants to UNPRELINK
>> the rootfs
>> before performing the upgrade?
>>
>> Prelink itself should still be run as a postprocess command that
>> takes the
>> output of the filesystem and reprocesses it.
>>
>> So something seems out of sync here.. (at a minimum probably should
>> be better
>> commented on why it's needed..)
> 
> The code is there for incremental opkg multilib image support. Its
> trying to compare whether binaries are identical. To make it work, it
> has to "unprelink" the files first before comparing.
> 
> I'm not convinced this is a good idea :/. I'm wondering if incremental
> image generation makes sense at all in this context to be honest.
> 
> Cheers,
> 
> Richard
>