As written in the topic, dev-libs/libpcre-8.33-r1 should use build_binaries() function instead of multilib_is_native_abi() function to conditionally build binaries.
should be multilib_build_binaries instead of build_binaries
ahah so now, after ignoring my remarks on how broken this is and committing it regardless, you are filling bugs requesting people to change their ebuilds to your brokenness ? nice in case you had not noticed, libpcre deps will be broken if one sets COMPLETE_MULTILIB after the change you are suggesting...
(In reply to Alexis Ballier from comment #2) > ahah > > so now, after ignoring my remarks on how broken this is and committing it > regardless, you are filling bugs requesting people to change their ebuilds > to your brokenness ? nice So if people could build packages for all ABIs and could even get binaries for them, that is broken? And if you convert the ebuild and disable the building of the binaries for the none-default ABIs, that is an advantage? Finally at least allowing those people to again build binaries for the none-default ABIs is then broken again in your eyes? > > > in case you had not noticed, libpcre deps will be broken if one sets > COMPLETE_MULTILIB after the change you are suggesting... You assume, that this is done blindly? Seems like you dont assume anyone could satisfy the needed dependencies before setting this variable? Anyway, this requested change just allows users to do something which was possible before the multilib conversion and still keeps the default to not building none-default binaries, so any reason beside "but users have another way to break things, if they try hard enough" against this change?
this is not really the place to discuss this so i'll try to keep it short (In reply to Thomas Sachau from comment #3) > (In reply to Alexis Ballier from comment #2) > > ahah > > > > so now, after ignoring my remarks on how broken this is and committing it > > regardless, you are filling bugs requesting people to change their ebuilds > > to your brokenness ? nice > > So if people could build packages for all ABIs and could even get binaries > for them, that is broken? they could not; if you're talking about multilib-portage: there is absolutely no mention of it here nor in the multilib_build_binaries documentation > And if you convert the ebuild and disable the building of the binaries for > the none-default ABIs, that is an advantage? yes; this avoids building useless stuff and was a request of the maintainers iirc > Finally at least allowing those people to again build binaries for the > none-default ABIs is then broken again in your eyes? if "allowing" means having deps not matching the requirements then it is obviously broken; that's like the 3rd time I tell you this > > in case you had not noticed, libpcre deps will be broken if one sets > > COMPLETE_MULTILIB after the change you are suggesting... > > You assume, that this is done blindly? your report just asks to do it like that, yes > Seems like you dont assume anyone > could satisfy the needed dependencies before setting this variable? the ebuild must have proper deps to ensure this; that there exists a way to make it work with a portage fork is irrelevant
(In reply to Alexis Ballier from comment #4) > this is not really the place to discuss this so i'll try to keep it short because this bug is not the right place to discuss, i will reply in a mail to you. @base-system: please continue as requested
should be all set now in the tree; thanks for the report! Commit message: Use multilib_build_binaries helper http://sources.gentoo.org/dev-libs/libpcre/libpcre-8.34.ebuild?r1=1.1&r2=1.2
probably fixed by that commit, but someone should double check
in the meantime it has shown that the multilib_build_binaries is a drop-in replacement for multilib_is_default_abi so all calls should condition on multilib_build_binaries unless they are explicitly only doing something usefull on the default ABI. So please replace all multilib_is_default_abi calls with multilib_build_binaries
(In reply to Thomas Sachau from comment #8) i dont like conflating unrelated concepts. if they mean the same thing, then wtf did we bother introducing this second func in the first place ?
