[OE-core] Prelink problem

[Mark Hatle]

On 1/16/19 1:23 AM, Andrej Valek wrote:
> 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.

If the image stuff needs prelink, there should be a dependency in place.  It
should only use prelink if the image-prelink is being used.

So really something probably needs to be added to image-prelink class that
activates unprelink behavior with opkg, and adds the necessary dependency.

--Mark

> 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
>>