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 93D9178984 for ; Tue, 17 Jul 2018 20:21:43 +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 w6HKLhiX028261 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Jul 2018 13:21:44 -0700 Received: from soho-mhatle-m.local (172.25.36.228) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.399.0; Tue, 17 Jul 2018 13:21:42 -0700 To: Kang Kai , References: <969ccd61-7a03-a81f-c36f-04c5d806d3e2@windriver.com> <22df428a-c981-bd8f-254d-739296926401@windriver.com> <1018c740-a3f2-2fb3-366e-f93615beef51@windriver.com> From: Mark Hatle Openpgp: preference=signencrypt Autocrypt: addr=mark.hatle@windriver.com; prefer-encrypt=mutual; keydata= xsBNBFYKxFgBCACt/pzutBp6p/xVKTFJjHbM3KpQKCblyot/YP+bpTr51Hrc5xDXBQhoG7TC aIRvRIvbhEevEQK9y04gW3JK/5lobq5ORebolcsHlYBUvpNeIPjupLQwGvz/TPtrLRNGLqDC rvsM6OA2XbQ2bwzxWaSQS3ImE2O2iXOZn9HhThMGeDB4Nff3fgUvXOTDIrgWOn9K2DgLL7Yc zkUIlFdj+Nraksd/7BSk8oH6tjeBVhFqSFvKta9QxWgdr58oPaTYaW/xNqUjlLrbJuMw/MSe xzuYfdfDfm6J8kRjMOnwQ0n8svJElzqAk+d83ow38gpGQ+LkjGgnf8ZFJ4rUJFADroX3ABEB AAHNJU1hcmsgSGF0bGUgPG1hcmsuaGF0bGVAd2luZHJpdmVyLmNvbT7CwHcEEwEIACEFAlYK xFgCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQfv796/r0vvlvZAf9Gs+eN320yhRW V/fZCsngKhmOK4v3HrTwFrkSmoD9QHQiE/5IPdNacHwIPwZx07tNBohB8xOeNqCPRYRBwGhA AnxKOPyd0nnm6ZhPzbA57v4x3IGRQr4QzvcBTASJq91l3Ew4lpAslyx5w1DPPqRD7G8ycDKg peKyDwmdkvCunVisSAQI3XIMq2y230biTO98tDPEezg+lg+yTsz9ZT33F5KNuWrpf8VL5fG/ mt+kAv7wtsx/KTRbqhH3iFXF6eBSwMjAfTXFlkLfbM9riJGXrWEl9n2S2R3cDHNHug0lb8f4 whK370KEO4OwRKIYW/VUBmzk5XZUE9DTlDSV8ycsrs7ATQRWCsRYAQgAwK3FuHCE+HW3YWdH PUjeSn5p//xJ57u8g2rng8zm9zNjmYgpPv5UxozaD9i2jf4mlQLHGGOezhHae8K4Nj70oVcv 8AmwcrJa9i9WL1oy/9R3fHMWf/Ctt9VXTO0qlCuq6PDzaUfvsXR61aJIjTKNQTOjCLjY1vXm VSewUgARysmA8WrjTfwGBihMBxAX0+kIjx8nOlam0WvekMBXZ0AbS56oTLRxYao6DI3GeB/N oWPy/5DfuTKaSdM0Pf8al20x9RuNN5/HLMlyDH/k8bIa1xd9aAqW+Feiw5gC107V2E6ULyIy q6em2UrsmIRxrvpHqbNgQKqvTehJ+V/i4g/uOwARAQABwsBfBBgBCAAJBQJWCsRYAhsMAAoJ EH7+/ev69L755XAH/3ZcNhooqd9OBhFkvXm1iWZ8EoC7motWqVn2oEyxoonsg8AD9kFXiN+T dYp7dH99EZu9q4ptj56AXm4uHzOgywL/5/V2TY6twCGAjUGzDjAB5gzoi+JLIBlDiyOip0eL QswIhRk473xy3j8DA4oVamnSPWgyNJ+qsdt37YWDzoDFFvtDoRU7Eb+znfIMDKzlny0XU/8L cW1bNHJlpv/78GPdfP4tjysEd8MuA5jf5o5w4XqcwTqalffEJtQ/s3pbkstEi7qm5uPui5Kt gq6YYLSqcSNe0GWAF9/T+qwyo7burSTxUWCWtMmlXdAQLW9SynLhB3Jbch0nFAh0fCKi6yY= Organization: Wind River Systems Message-ID: <24847408-a32e-2109-8b5d-c718e900cb9f@windriver.com> Date: Tue, 17 Jul 2018 15:21:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1018c740-a3f2-2fb3-366e-f93615beef51@windriver.com> Subject: Re: [RFC] How to deal allarch packages in dependency chain for multilib rootfs? 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: Tue, 17 Jul 2018 20:21:43 -0000 Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit On 7/2/18 3:50 AM, Kang Kai wrote: > On 2018年06月28日 22:26, Mark Hatle wrote: >> On 6/28/18 3:48 AM, Kang Kai wrote: >>> Hi all, >>> >>> When build 32 bits rootfs with 64 bits bsp, if an allarch/noarch package is >>> installed to lib32 rootfs, it causes >>> unexpected 64 bits packages which is required by the allarch package installed >>> to lib32 rootfs. >>> >>> Take ca-certificates as example. ca-certificates rdepends on openssl, so if >>> ca-certificates is installed to image, >>> 64 bits package openssl will be installed too no matter what the rootfs is. But >>> only 32 bits openssl package should >>> be installed to 32 bits rootfs. > > Hi Mark, > > Thanks for your detailed reply. > >> With -RPM-, and using names that do not include 'lib32' or other multilib >> prefixes. RPM doesn't care 'who' provides openssl, as long as someone provides >> openssl. There is a series of weights added to the available providers of >> openssl. The package with the highest weight (or maybe lowest) is what ends up >> being installed. >> >> In the case where there are two multilibs providing openssl, the system will >> usually do one of two things: >> >> 1) Look to see if an existing openssl is set to be installed (just use that version) >> >> 2) Look to see if the default architecture has the package and use that, >> otherwise fall back to less priority architectures. (Again, this is stock RPM >> behavior.) >> >> OE has modified the behaviors slightly, so I can't be 100% confident as to how >> it works in OE in all cases. > > Do you mean make lib32-openssl also provides openssl? It should work for > do rootfs with repo priorities. But my concern is that > install package -foo- which requires openssl during runtime by command > rpm. If lib32-openssl is installed and it also provides 'openssl', > then package -foo- could be installed without real 64bits openssl. It > may cause malfunction. RPM has ELF dependencies and named dependencies. The named dependencies (at least in the past) had been translated to the generic name, as well as the multilib name. This allowed someone to say 'give me openssl', and it didn't matter which. For another package that required libssl (64-bit) it would have had a dependency on libssl(64) added to it, automatically, by the packaging system when building RPMs. These dependencies are only added when using RPMs, and there is (intentionally) no manual way to specify them. Where this falls down is perl where we might have a 32-bit and/or 64-bit perl.. and we wanted one or the other for a specific module. Pam historically had a similar problem as the PAM subsystem was 64-bit -- but for some reason we'd end up installing only the 32-bit components. (Mind you as far as I know neither of these cases are part of the allarch issues you are concerned with.) >>> There are 2 ways to fixed the issue. >>> >>> 1 expand allarch/noarch packages with multilib. So if add ca-certificates to >>> image, lib32-ca-certificates will be >>>    installed to 32bits rootfs. And then also the dependency lib32-openssl is >>> installed. That is what we expected. >> This really isn't the right way to do it, because then you end up with two >> packages with identical content -- and you then need to ensure that the internal >> dependencies all 'match'. >> >> So you've added another layer where you need to ensure that the multilib >> rdepends are 'specified' and managed properly. [Yes this can be handled by OE >> automaticallly], but it doubles the size of the package respository (for no-arch >> packages), as well as any field upgrades BOTH have to be upgraded together or >> you will get an error. > > Got it. > >> >>> 2 expand DEPENDS/RDEPENDS of allarch/noarch packages with a prefix 'noarch-' >>> when multilib is enabled. So then >>>    ca-certificates requires 'noarch-openssl'. And make both lib32-openssl and >>> openssl provides 'noarch-openssl'. >> -today- it should be depending on 'openssl', and all variants of openssl SHOULD >> be calling themselves/providing 'openssl'. (The other components of the >> dependency system will ensure the right 32-bit/64-bit version is selected if >> needed.) >> >> And unless the image creator is explicit in their check they may end up with >> BOTH the 32-bit and 64-bit versions... >> >>>    When do_rootfs, there is only one rpm repo 'oe-rootfs-repo' now. We will >>> create repos with different priorities >> And this is creating problems. This is why the priority system (order for >> dependencies) was put into place originally. So it would start at the highest >> priority components and work it's way until it found the right set of matches. >> >> With DNF and RPM(4), things have changed.. I'm not sure how the priorities are >> defined in this system -- but really each arch type should be it's own >> repository in DNF.. and the priorities for each should be ordered to match the >> user's preferred order for package installation. (The default behavior is fine >> for most users, but a way to say -- no really I want 32-bit installed first.. is >> needed for the multilib image cases..) > > Thanks. I'll figure out the priority in DNF and RPM(4). > >> >> The reality though for most multilib users is they have one of two use-cases: >> >> 1) 64-bit kernel, 32-bit userspace (and possibly a 'few' 64-bit binaries) >> >> 2) 64-bit kernel, 64-bit userspace... They want a small number of libraries from >> the multilib installed into their main system >> >> It's the second case where we often get into problems, because the system is >> really intended for that -- where you would say I expect BOTH openssl 32-bit and >> 64-bit installed, but many of our users are trying to do I want only the openssl >> installed for the executables I need. (reasonable request, just not exactly >> what RPM was intended to be doing.) >> >>>    according to different archs/subdirectories. For 32 bits image, make 32 bits >>> rpm repo has  higher priority, so lib32-openssl >>>    will be installed to 32 bits rootfs rather than 64bits. >> Yes, this covers the use case #1 better then anything else we have at this point. >> >>> I know these 2 ways are not perfect, but only possible ways I have in mind to >>> solve the problem. >>> >>> Any comment or suggestion is greatly appreciated. Thanks a lot. >> So I can sum this up to: >> >> Use case 1.. kernel and primary userspace library type don't match is >> problematic, but not used by a lot of people (AFAIK). > > I am sorry that it is the Use case 1 (64-bit kernel, 32-bit userspace) > that we want to solve. Because both lib32 (imported by other lib32 > packages) and > 64bits (imported by noarch pacakge) packages such as perl may be > installed to image at same time , it causes some runtime failures such > as some perl > modules don't work. There should -never- be a situation with a 32-bit and 64-bit (or any multilib) 'allarch' package changes. If it does, it's simply NOT allarch. Allarch means there are no architecture dependencies in that package. If there are -any-, the thing should be properly declared to a specific arch, even if it only contains configuration files. Maybe the right answer is to add a QA step that verifies all 'allarch' versions are the same.. (I'm not exactly sure how you would do this, try to build all 'multilib' variants of any specific allarch and verify they didn't change perhaps?) > I once thought to solve the dependency issue in package libsolv. The > original thought is to pass a environment variable to identify whether > build a lib32 image. > When resolve the dependencies of noarch package, expand the dependencies > according the environment variable. But it seems libsolv treats "all > strings and > relations as unique 32-bit numbers". So it seems it doesn't work this way. Ya, I don't think fixing it in the solver is the right answer. Whatever the solution, it has to be generic to work for all of the packaging formats. The basic rules, as I understand them, are: 1) allarch/noarch -- must be -identical- across all architectures [with the same distro configuration] 2) recipes/packages that require allarch must not expect any architecture dependent behavior, including path names. (lib vs lib64, etc) 3) regular arch packages should do dependencies based on package names (and other declared virtual dependencies) 4) rpm [automatic] internal dependencies should resolve executable dynamic linking issues. Known caveats are PAM, Perl and maybe Python modules that have no ELF component, but may have be loaded at runtime and need to match another executable environment. How to resolve this, we need to be explicit in the recipes.. i.e. a 32-bit pam module must require 32-bit pam and NOT satisfy a 64-bit applications PAM needs. (Not sure the above really helps, but it may clarify things a bit.) --Mark > > Thanks a lot. > > --Kai > >> >> Use case 2.. the embedded nature of trying to develop 'small' [in terms of >> number of packages installed] filesystems is causing some odd behavior, but a >> workaround of specifying the -exact- packages you want when this oddity arrives >> is available. >> >> --Mark >> >>> -- >>> Regards, >>> Neil | Kai Kang >>> >> >