From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E46D81384B4 for ; Mon, 4 Jan 2016 16:29:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A254721C006; Mon, 4 Jan 2016 16:29:44 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A3B22E087F for ; Mon, 4 Jan 2016 16:29:43 +0000 (UTC) Received: from [192.168.1.130] (CPE002401f30b73-CM78cd8ec1b205.cpe.net.cable.rogers.com [99.224.138.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id A62DF3405C3 for ; Mon, 4 Jan 2016 16:29:42 +0000 (UTC) Subject: Re: [gentoo-dev] Eclass assisted multilib dependent cache updates To: gentoo-dev@lists.gentoo.org References: <1451750071.31635.9.camel@gentoo.org> From: Ian Stakenvicius Message-ID: <568A9DF3.9060201@gentoo.org> Date: Mon, 4 Jan 2016 11:29:39 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <1451750071.31635.9.camel@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 7c667a4b-d02f-44a8-9b85-6696f3563405 X-Archives-Hash: 719767f1f479b8342133e85973ebc0fd -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/01/16 10:54 AM, Gilles Dartiguelongue wrote: > Hello all, > > while working on bug #518422, I found out that while eclass calls > the relevant cache updates it has no idea whether or not it is > called in a multilib context or not. > > Imho, this leads to avoidable human errors where one thinks > eclass will take care of lib dependent caches, which it does, but > not for all enabled ABIs which could lead to reduced > functionality for non-native ABIs. > > While it seems reasonable to call multilib_foreach_abi > gnome2_pkg_postinst for multilib enabled ebuilds, it is still not > ideal as it will call a lot of functions for no good reason. On > the other hand, checking environment variable set by multilib > eclasses does not seem like a robust solution. > > Is there any reasonable way to make phase functions aware of if > they are running in a multilib enabled ebuild to adjust their > behavior ? > By "phase functions" here, I assume that you are referring to phase functions exported by the eclass? In that particular case, AFAIK, they are never called in a multilib context by default, rather they are only called within a multilib context when explicitly called within a multilib_foreach_abi. Back to the issue at hand, though, likely there would be a way to leverage 'multilib_is_native_abi' to filter out cases when you don't want certain things to run. To do this properly for non-multilib ebuilds you'll need to make sure that your conditionals won't crash out if multilib_is_native_abi is undefined, though -- could be a messy hack... It would probably make more sense to rearrange the function(s) internally and perhaps provide two (one for multilib-build, one not) if the plan is to support ebuilds that inherit multilib-build AND ebuilds that don't, from the same eclass. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlaKnfMACgkQAJxUfCtlWe0xxQD/S0+QJMqm0qulSR4DAZb4J0uu RPF53KqIPkuvE0VnL14BAJWscEDyB4Pt9JOEjoiYwNelfDV0frwsgEQVvZu1Ol7Y =pZVV -----END PGP SIGNATURE-----