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.ha...@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 >> -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core