[gentoo-dev] Eclass assisted multilib dependent cache updates

[gentoo-dev] Eclass assisted multilib dependent cache updates

[Gilles Dartiguelongue]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

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 ?

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Eclass assisted multilib dependent cache updates

[Alexis Ballier]

On Sat, 02 Jan 2016 16:54:31 +0100
Gilles Dartiguelongue <eva@gentoo.org> 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.

Hmm... what's the problem here ?
What you seem to call "not a multilib context" is a multilib build with
only one ABI. That's one of the points of inheriting the
multilib eclasses.

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


Per the above, 'multilib_foreach_abi' seems just fine. Is there a real
problem with it?

Re: [gentoo-dev] Eclass assisted multilib dependent cache updates

[Ian Stakenvicius]

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