Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

[hasufell <hasufell@gentoo.org>]

Rich Freeman:
> On Tue, Jun 17, 2014 at 8:30 AM, hasufell <hasufell@gentoo.org> wrote:
>> No, that's not how opensource works. You don't work on things after
>> "upstream" said "not interested".
> 
> That is hardly true though - which is why we have 47 different
> implementations of everything to debate the merits of.  :)
> 

I was excluding the case of forks, because (IMO) it wouldn't make sense
if I start a sys-devel/crossdev-ng package.


The problem is that working around these bugs reliably currently
involves setting dangerous INSTALL_MASK, creating post_install hackery
hooks and additional things to keep crossdev together.

The proposed approach of removing it from PATH would make all this
obsolete and require crossdev users who don't care about this bug and
want the toolchain globally accessible in PATH to add a single line in
their profile/bashrc.

But this single line seems to be a major inconvenience which is reason
enough to break a valid use case.

> Is there a list/etc for crossdev?  I'd think that the users and
> maintainers of crossdev collectively have the biggest vested interest
> in addressing these issues.  They're also the ones who can vouch for
> how big of a problem this is.
> 
> Is this having some kind of adverse impact on anybody outside of the
> crossdev community?  If the crossdev maintainers were pushing hundreds
> of packages to change to accommodate dubious design on their part I
> could see this being a distro-wide issue.  On the other hand, if this
> is an issue that only impacts crossdev users and maintainers, then I'd
> think the simplest solution would be let them sort it out.
> 

I am a crossdev user (I don't just have it installed for fun).


Currently, we don't have any way to communicate this broken use case to
the user. That's not a good situation.

And my hopes for "let them sort it out" are so low, that I won't wait
for it (look at their responses... they consist of colorful threats,
saying "bs" and telling me that I do "dumb" things).


So from my side I can do a number of things:
1) block crossdev from within multilib-minimal.eclass... that brings me
to the question how to do it:
  a) just block sys-devel/crossdev if any non-native ABI is activated:
     pretty rough and will make some people angry
  b) e.g. block cross-i686-pc-linux-gnu/gcc if ABI_X86="32" is
     activated: repoman will probably kill me
  c) do some sophisticated checks in a phase function that will call
     "die" if the the broken use case is detected: pretty hacky, but
     more safe than the current situation
2) print an elog that no one will read

All of the solutions above still leave the use case broken.