From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail5.wrs.com (mail5.windriver.com [192.103.53.11]) by mail.openembedded.org (Postfix) with ESMTP id 5435F7C187 for ; Wed, 16 Jan 2019 15:58:37 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail5.wrs.com (8.15.2/8.15.2) with ESMTPS id x0GFvWuk009458 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jan 2019 07:57:43 -0800 Received: from soho-mhatle-m.local (172.25.36.231) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.408.0; Wed, 16 Jan 2019 07:57:22 -0800 To: Andrej Valek , Richard Purdie , "Burton, Ross" References: <05af53a7-6ed6-9615-be2e-d8c31dbfb321@siemens.com> <7497c039-7951-ee51-7506-300a74d0b558@windriver.com> From: Mark Hatle Openpgp: preference=signencrypt Autocrypt: addr=mark.hatle@windriver.com; prefer-encrypt=mutual; keydata= mQENBFYKxFgBCACt/pzutBp6p/xVKTFJjHbM3KpQKCblyot/YP+bpTr51Hrc5xDXBQhoG7TC aIRvRIvbhEevEQK9y04gW3JK/5lobq5ORebolcsHlYBUvpNeIPjupLQwGvz/TPtrLRNGLqDC rvsM6OA2XbQ2bwzxWaSQS3ImE2O2iXOZn9HhThMGeDB4Nff3fgUvXOTDIrgWOn9K2DgLL7Yc zkUIlFdj+Nraksd/7BSk8oH6tjeBVhFqSFvKta9QxWgdr58oPaTYaW/xNqUjlLrbJuMw/MSe xzuYfdfDfm6J8kRjMOnwQ0n8svJElzqAk+d83ow38gpGQ+LkjGgnf8ZFJ4rUJFADroX3ABEB AAG0JU1hcmsgSGF0bGUgPG1hcmsuaGF0bGVAd2luZHJpdmVyLmNvbT6JATcEEwEIACEFAlYK xFgCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQfv796/r0vvlvZAf9Gs+eN320yhRW V/fZCsngKhmOK4v3HrTwFrkSmoD9QHQiE/5IPdNacHwIPwZx07tNBohB8xOeNqCPRYRBwGhA AnxKOPyd0nnm6ZhPzbA57v4x3IGRQr4QzvcBTASJq91l3Ew4lpAslyx5w1DPPqRD7G8ycDKg peKyDwmdkvCunVisSAQI3XIMq2y230biTO98tDPEezg+lg+yTsz9ZT33F5KNuWrpf8VL5fG/ mt+kAv7wtsx/KTRbqhH3iFXF6eBSwMjAfTXFlkLfbM9riJGXrWEl9n2S2R3cDHNHug0lb8f4 whK370KEO4OwRKIYW/VUBmzk5XZUE9DTlDSV8ycsrrkBDQRWCsRYAQgAwK3FuHCE+HW3YWdH PUjeSn5p//xJ57u8g2rng8zm9zNjmYgpPv5UxozaD9i2jf4mlQLHGGOezhHae8K4Nj70oVcv 8AmwcrJa9i9WL1oy/9R3fHMWf/Ctt9VXTO0qlCuq6PDzaUfvsXR61aJIjTKNQTOjCLjY1vXm VSewUgARysmA8WrjTfwGBihMBxAX0+kIjx8nOlam0WvekMBXZ0AbS56oTLRxYao6DI3GeB/N oWPy/5DfuTKaSdM0Pf8al20x9RuNN5/HLMlyDH/k8bIa1xd9aAqW+Feiw5gC107V2E6ULyIy q6em2UrsmIRxrvpHqbNgQKqvTehJ+V/i4g/uOwARAQABiQEfBBgBCAAJBQJWCsRYAhsMAAoJ EH7+/ev69L755XAH/3ZcNhooqd9OBhFkvXm1iWZ8EoC7motWqVn2oEyxoonsg8AD9kFXiN+T dYp7dH99EZu9q4ptj56AXm4uHzOgywL/5/V2TY6twCGAjUGzDjAB5gzoi+JLIBlDiyOip0eL QswIhRk473xy3j8DA4oVamnSPWgyNJ+qsdt37YWDzoDFFvtDoRU7Eb+znfIMDKzlny0XU/8L cW1bNHJlpv/78GPdfP4tjysEd8MuA5jf5o5w4XqcwTqalffEJtQ/s3pbkstEi7qm5uPui5Kt gq6YYLSqcSNe0GWAF9/T+qwyo7burSTxUWCWtMmlXdAQLW9SynLhB3Jbch0nFAh0fCKi6yY= Organization: Wind River Systems Message-ID: <9018fe34-658e-4da4-3ea5-e2fc7eb5bb79@windriver.com> Date: Wed, 16 Jan 2019 09:57:21 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Cc: "openembedded-core@lists.openembedded.org" Subject: Re: Prelink problem X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 15:58:38 -0000 Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit 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 >>>> 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 >>