crossdev and multilib interference

classic Classic list List threaded Threaded
85 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

hasufell
Jeroen Roovers:

> On Mon, 16 Jun 2014 19:31:58 +0000
> hasufell <[hidden email]> wrote:
>
>> Also check the history of this thread for a few proposed solutions.
>
> The history of this thread and the history of gx86-multilib and
> crossdev development suggest that crossdev was doing nothing wrong until
> gx86-multilib came around and a problem was found between them. Masking
> either for the benefit of the other would be, and let me quote the
> history of this thread out of context just to fit in with the tone and
> mode this sub-thread has taken, "asinine".
>

This isn't about right or wrong. This is about actual breakage on stable
systems.

Solutions were proposed, nothing has happened for months.

So I don't see what else we can do here other than taking more radical
steps to INFORM users of these possible breakages... and that's exactly
what a hardmask is for.

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

Joshua Kinard-2
On 06/16/2014 15:47, hasufell wrote:

> Jeroen Roovers:
>> On Mon, 16 Jun 2014 19:31:58 +0000
>> hasufell <[hidden email]> wrote:
>>
>>> Also check the history of this thread for a few proposed solutions.
>>
>> The history of this thread and the history of gx86-multilib and
>> crossdev development suggest that crossdev was doing nothing wrong until
>> gx86-multilib came around and a problem was found between them. Masking
>> either for the benefit of the other would be, and let me quote the
>> history of this thread out of context just to fit in with the tone and
>> mode this sub-thread has taken, "asinine".
>>
>
> This isn't about right or wrong. This is about actual breakage on stable
> systems.
>
> Solutions were proposed, nothing has happened for months.
>
> So I don't see what else we can do here other than taking more radical
> steps to INFORM users of these possible breakages... and that's exactly
> what a hardmask is for.

What about those of us who have been using crossdev to generate
cross-compilers for years w/o issue, because we run non-multilib?
Hardmasking crossdev to solve multilib problems doesn't accomplish anything,
other than just irk us.  Why not hardmask the multilib stuff instead and
leave crossdev alone?

Neither hardmask solution is viable, since you'll inconvenience one side for
the sake of the other.  That's not how you solve problems.

Is my understanding of the issue correct, in that, per Bug #500338, crossdev
was used to merge an i686-pc-linux-gnu cross-toolchain onto an
x86_64-pc-linux-gnu system, resulting in /usr/bin/cross-pkg-config being
linked to /usr/bin/i686-pc-linux-gnu-pkg-config, which causes the problem
reported in that bug?

If so, is it sensible to allow crossdev to install a cross-toolchain when
the underlying machine architecture is the same, just a different ABI?
I.e., would a solution be to prevent i686-on-x86_64 or mips64-on-mips, but
still allow mips64-on-x86_64, and such?

--
Joshua Kinard
Gentoo/MIPS
[hidden email]
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

hasufell
Joshua Kinard:

> On 06/16/2014 15:47, hasufell wrote:
>> Jeroen Roovers:
>>> On Mon, 16 Jun 2014 19:31:58 +0000
>>> hasufell <[hidden email]> wrote:
>>>
>>>> Also check the history of this thread for a few proposed solutions.
>>>
>>> The history of this thread and the history of gx86-multilib and
>>> crossdev development suggest that crossdev was doing nothing wrong until
>>> gx86-multilib came around and a problem was found between them. Masking
>>> either for the benefit of the other would be, and let me quote the
>>> history of this thread out of context just to fit in with the tone and
>>> mode this sub-thread has taken, "asinine".
>>>
>>
>> This isn't about right or wrong. This is about actual breakage on stable
>> systems.
>>
>> Solutions were proposed, nothing has happened for months.
>>
>> So I don't see what else we can do here other than taking more radical
>> steps to INFORM users of these possible breakages... and that's exactly
>> what a hardmask is for.
>
> What about those of us who have been using crossdev to generate
> cross-compilers for years w/o issue, because we run non-multilib?
> Hardmasking crossdev to solve multilib problems doesn't accomplish anything,
> other than just irk us.  Why not hardmask the multilib stuff instead and
> leave crossdev alone?
>

Hardmask half of the tree instead of a single package? Does not sound
reasonable. The fallout will be _huge_ for users who already run
multilib. You will basically get an emerge dump of 500+ blockers.

>
> If so, is it sensible to allow crossdev to install a cross-toolchain when
> the underlying machine architecture is the same, just a different ABI?
> I.e., would a solution be to prevent i686-on-x86_64 or mips64-on-mips, but
> still allow mips64-on-x86_64, and such?
>

That was already discussed and it will break:
> yes, serving as a distcc server for x86 hosts or using 'cross emerge'
> to build a x86 root from scratch

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

hasufell
In reply to this post by Steev Klimaszewski-2
Steev Klimaszewski:
>
> while I agree that temporarily adding the cross
> compiler(s) to the PATH is easy, for some of us, it's easier to allow
> Gentoo to do so.

I'm not sure if that is reason enough to cause the current breakage
crossdev and multilib are in.


Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

Ian Stakenvicius-2
In reply to this post by Joshua Kinard-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/06/14 04:05 PM, Joshua Kinard wrote:

> On 06/16/2014 15:47, hasufell wrote:
>> So I don't see what else we can do here other than taking more
>> radical steps to INFORM users of these possible breakages... and
>> that's exactly what a hardmask is for.
>
> What about those of us who have been using crossdev to generate
> cross-compilers for years w/o issue, because we run non-multilib?
> Hardmasking crossdev to solve multilib problems doesn't accomplish
> anything, other than just irk us.  Why not hardmask the multilib
> stuff instead and leave crossdev alone?

well, we could hardmask in the multilib profiles...  but that's a bit
of a digression


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlOfUyYACgkQ2ugaI38ACPA1TAD+JYjgKnwabCy9qPiwZAKgXkxH
Nj4kzhLSQ0HF+5CCHIYBAKEG8Yt65JhTIKOCwEHLx+7Kh4p0xtZcVBLnE3dIROrf
=iyqN
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

Joshua Kinard-2
In reply to this post by hasufell
On 06/16/2014 16:24, hasufell wrote:

> Joshua Kinard:
>> On 06/16/2014 15:47, hasufell wrote:
>>> Jeroen Roovers:
>>>> On Mon, 16 Jun 2014 19:31:58 +0000
>>>> hasufell <[hidden email]> wrote:
>>>>
>>>>> Also check the history of this thread for a few proposed solutions.
>>>>
>>>> The history of this thread and the history of gx86-multilib and
>>>> crossdev development suggest that crossdev was doing nothing wrong until
>>>> gx86-multilib came around and a problem was found between them. Masking
>>>> either for the benefit of the other would be, and let me quote the
>>>> history of this thread out of context just to fit in with the tone and
>>>> mode this sub-thread has taken, "asinine".
>>>>
>>>
>>> This isn't about right or wrong. This is about actual breakage on stable
>>> systems.
>>>
>>> Solutions were proposed, nothing has happened for months.
>>>
>>> So I don't see what else we can do here other than taking more radical
>>> steps to INFORM users of these possible breakages... and that's exactly
>>> what a hardmask is for.
>>
>> What about those of us who have been using crossdev to generate
>> cross-compilers for years w/o issue, because we run non-multilib?
>> Hardmasking crossdev to solve multilib problems doesn't accomplish anything,
>> other than just irk us.  Why not hardmask the multilib stuff instead and
>> leave crossdev alone?
>>
>
> Hardmask half of the tree instead of a single package? Does not sound
> reasonable. The fallout will be _huge_ for users who already run
> multilib. You will basically get an emerge dump of 500+ blockers.
>

Which is why I followed with the next paragraph that neither hardmask
solution is really viable.  You inconvenience a group of people one way or
the other, even if you're only doing it just to raise a point and/or awareness.

>>
>> If so, is it sensible to allow crossdev to install a cross-toolchain when
>> the underlying machine architecture is the same, just a different ABI?
>> I.e., would a solution be to prevent i686-on-x86_64 or mips64-on-mips, but
>> still allow mips64-on-x86_64, and such?
>>
>
> That was already discussed and it will break:
>> yes, serving as a distcc server for x86 hosts or using 'cross emerge'
>> to build a x86 root from scratch

Then, can crossdev be augmented to work around the invalid behavior?  Has
anyone looked at crossdev's source to see if the issue can be corrected with
a patch?  Can the offending feature be made optional via a USE flag?  There
are other options available than simply hardmasking a package that many find
useful.

--
Joshua Kinard
Gentoo/MIPS
[hidden email]
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Reply | Threaded
Open this post in threaded view
|

Re: crossdev and multilib interference

Jeroen Roovers-3
In reply to this post by Ian Stakenvicius-2
On Mon, 16 Jun 2014 16:27:19 -0400
Ian Stakenvicius <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 16/06/14 04:05 PM, Joshua Kinard wrote:
> > On 06/16/2014 15:47, hasufell wrote:
> >> So I don't see what else we can do here other than taking more
> >> radical steps to INFORM users of these possible breakages... and
> >> that's exactly what a hardmask is for.
> >
> > What about those of us who have been using crossdev to generate
> > cross-compilers for years w/o issue, because we run non-multilib?
> > Hardmasking crossdev to solve multilib problems doesn't accomplish
> > anything, other than just irk us.  Why not hardmask the multilib
> > stuff instead and leave crossdev alone?
>
> well, we could hardmask in the multilib profiles...  but that's a bit
> of a digression

OK, let's sum it up.

We have multilib users.

We have crossdev users.

Some multilib users are crossdev users.

Some multilib users who are crossdev users have built a cross-toolchain.

Some multilib users who have built a cross-toolchain experience bug
#500338.

Masking crossdev would cause issues for all crossdev users.

Masking multilib would cause issues for all multilib users.

Masking crossdev on multilib profiles would cause issues for all users
of both crossdev and multilib who haven't built a cross-toolchain that
irks multilib

Masking crossdev on multilib profiles would also cause issues for all
users of both crossdev and multilib who haven't built a cross-toolchain
at all but now find they want to and run into bug #500338.

In short, masking crossdev in any of the above ways results in very
little progress, and is detrimental to solving the issue since the mask
would prevent testing on a wide range of platforms because of the
inconvenience that masking causes, deterring people from even trying.

     jer

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

hasufell
In reply to this post by Joshua Kinard-2
Joshua Kinard:
>
> Then, can crossdev be augmented to work around the invalid behavior?

Yes, by installing it into prefixes and requiring people to add it to
PATH on their own if they need it outside of cross-emerge.

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

Patrick Lauer
In reply to this post by hasufell
On 06/17/2014 04:24 AM, hasufell wrote:

>> What about those of us who have been using crossdev to generate
>> cross-compilers for years w/o issue, because we run non-multilib?
>> Hardmasking crossdev to solve multilib problems doesn't accomplish anything,
>> other than just irk us.  Why not hardmask the multilib stuff instead and
>> leave crossdev alone?
>>
>
> Hardmask half of the tree instead of a single package? Does not sound
> reasonable. The fallout will be _huge_ for users who already run
> multilib. You will basically get an emerge dump of 500+ blockers.

That's not a bug ;)

Since I can't figure out how any of these multibuilds work (that's no
longer an ebuild ...) I'm not opposed to have them removed from my
workflow.

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

Joshua Kinard-2
In reply to this post by hasufell
On 06/16/2014 18:10, hasufell wrote:
> Joshua Kinard:
>>
>> Then, can crossdev be augmented to work around the invalid behavior?
>
> Yes, by installing it into prefixes and requiring people to add it to
> PATH on their own if they need it outside of cross-emerge.

How big of a patch would this change require to the existing crossdev ebuild?

Can $PATH be configured via our existing eselect tool to enable/disable the
crossdev paths when needed?

--
Joshua Kinard
Gentoo/MIPS
[hidden email]
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Reply | Threaded
Open this post in threaded view
|

Re: crossdev and multilib interference

Joshua Kinard-2
In reply to this post by Jeroen Roovers-3
On 06/16/2014 17:42, Jeroen Roovers wrote:

> On Mon, 16 Jun 2014 16:27:19 -0400
> Ian Stakenvicius <[hidden email]> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On 16/06/14 04:05 PM, Joshua Kinard wrote:
>>> On 06/16/2014 15:47, hasufell wrote:
>>>> So I don't see what else we can do here other than taking more
>>>> radical steps to INFORM users of these possible breakages... and
>>>> that's exactly what a hardmask is for.
>>>
>>> What about those of us who have been using crossdev to generate
>>> cross-compilers for years w/o issue, because we run non-multilib?
>>> Hardmasking crossdev to solve multilib problems doesn't accomplish
>>> anything, other than just irk us.  Why not hardmask the multilib
>>> stuff instead and leave crossdev alone?
>>
>> well, we could hardmask in the multilib profiles...  but that's a bit
>> of a digression
>
> OK, let's sum it up.
>
> We have multilib users.
>
> We have crossdev users.
>
> Some multilib users are crossdev users.
>
> Some multilib users who are crossdev users have built a cross-toolchain.
>
> Some multilib users who have built a cross-toolchain experience bug
> #500338.
>
> Masking crossdev would cause issues for all crossdev users.
>
> Masking multilib would cause issues for all multilib users.
>
> Masking crossdev on multilib profiles would cause issues for all users
> of both crossdev and multilib who haven't built a cross-toolchain that
> irks multilib
>
> Masking crossdev on multilib profiles would also cause issues for all
> users of both crossdev and multilib who haven't built a cross-toolchain
> at all but now find they want to and run into bug #500338.
>
> In short, masking crossdev in any of the above ways results in very
> little progress, and is detrimental to solving the issue since the mask
> would prevent testing on a wide range of platforms because of the
> inconvenience that masking causes, deterring people from even trying.
>
>      jer

+1

--
Joshua Kinard
Gentoo/MIPS
[hidden email]
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

hasufell
In reply to this post by Joshua Kinard-2
Joshua Kinard:
>
> How big of a patch would this change require to the existing crossdev ebuild?
>

Probably quite trivial, but since vapier said "bs" to that proposal
(translates to "bullshit" I guess) I'll not put any work into that.

So there we go. If you are cool, you can just say "bs", vanish and leave
stable arch in a broken state.

Not even QA cares. Great. I'll try to get it on the next council agenda
then.

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

Joshua Kinard-2
On 06/16/2014 21:47, hasufell wrote:

> Joshua Kinard:
>>
>> How big of a patch would this change require to the existing crossdev ebuild?
>>
>
> Probably quite trivial, but since vapier said "bs" to that proposal
> (translates to "bullshit" I guess) I'll not put any work into that.
>
> So there we go. If you are cool, you can just say "bs", vanish and leave
> stable arch in a broken state.
>
> Not even QA cares. Great. I'll try to get it on the next council agenda
> then.

So you just take your ball and go home then?  That's not how it works.

Create the patch, and file it as a bug.  Then, raise awareness on the ML.
That's how development works.  If your patch is reasonable and doesn't break
things, odds are likely it'll push the other members of toolchain to
consider incorporating it.

Equally using the Council as a hammer all the time doesn't work in the
long-term, either.  If you whip a patch up, however, then not only could you
raise this at the next council meeting, but additionally state you've gone
that extra mile and created a patch that addresses the problem.

That's taking the ball and putting it into the goal.

--
Joshua Kinard
Gentoo/MIPS
[hidden email]
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Reply | Threaded
Open this post in threaded view
|

Re: crossdev and multilib interference

Ryan Hill
In reply to this post by hasufell
On Mon, 16 Jun 2014 13:27:29 +0000
hasufell <[hidden email]> wrote:

> If you think having broken packages for months in stable arch is ok,
> then you are wrong.
>
> And btw., your funny threats don't impress me anymore.
>
> I'll bring this up to the council agenda if you like. This is a
> non-trivial tree-wide problem and if toolchain keeps ignoring it, then I
> will hardmask the thing.

Well, see, I'm trying funny threats because I don't know how else to get it
through your head that you have no right to start masking packages that don't
belong to you when we won't fix your stupid pet bug.  And if you do so there
will be consequences.  By masking crossdev you'd effectively be masking the
whole tree for any number of archs.  Not to mention anyone building a
cross-compiler for their own use outside of portage.  There are several
high-profile groups that rely on crossdev.  Hell, several arch teams rely on
it.  You're suggesting we mask it because your particular corner-case doesn't
work.  Maybe I should start threatening to remove games when they don't run
on my video card.

If doing something dumb like installing a i686 crossdev toolchain on
x86_64 breaks things, it's because you've done something dumb.  Stop doing
that and things should work better.


--
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

signature.asc (486 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: crossdev and multilib interference

hasufell
Ryan Hill:
> If doing something dumb like installing a i686 crossdev toolchain on
> x86_64 breaks things, it's because you've done something dumb.  Stop doing
> that and things should work better.
>

There have been several reasons mentioned to do what you call dumb. I'm
not going to repeat them. Read the thread.

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

hasufell
In reply to this post by Joshua Kinard-2
Joshua Kinard:

> On 06/16/2014 21:47, hasufell wrote:
>> Joshua Kinard:
>>>
>>> How big of a patch would this change require to the existing crossdev ebuild?
>>>
>>
>> Probably quite trivial, but since vapier said "bs" to that proposal
>> (translates to "bullshit" I guess) I'll not put any work into that.
>>
>> So there we go. If you are cool, you can just say "bs", vanish and leave
>> stable arch in a broken state.
>>
>> Not even QA cares. Great. I'll try to get it on the next council agenda
>> then.
>
> So you just take your ball and go home then?  That's not how it works.
>
> Create the patch, and file it as a bug.  Then, raise awareness on the ML.
> That's how development works.  If your patch is reasonable and doesn't break
> things, odds are likely it'll push the other members of toolchain to
> consider incorporating it.
>
> Equally using the Council as a hammer all the time doesn't work in the
> long-term, either.  If you whip a patch up, however, then not only could you
> raise this at the next council meeting, but additionally state you've gone
> that extra mile and created a patch that addresses the problem.
>
> That's taking the ball and putting it into the goal.
>

No, that's not how opensource works. You don't work on things after
"upstream" said "not interested".

https://bugs.gentoo.org/show_bug.cgi?id=504824

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

hasufell
In reply to this post by Joshua Kinard-2
Joshua Kinard:
>
> Equally using the Council as a hammer all the time doesn't work in the
> long-term, either.

This is exactly the case where the council has to step in to solve
global issues and those between projects (here it is embedded gentoo
project and multilib project).

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

Rich Freeman
In reply to this post by hasufell
On Tue, Jun 17, 2014 at 8:30 AM, hasufell <[hidden email]> 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.  :)

Besides, if this were truly an "upstream" issue the Council could
hardly do anything about it.

The solution to this problem isn't annoying crossdev users in the hope
that they will pester the crossdev maintainers.  In theory they're the
main ones impacted by the bug in the first place.

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.

If somebody in the crossdev community does want to sort it out and the
problem is package squatting, then that might be a valid reason to
escalate.  In that case the cleanest solution is to have a crossdev
project, have the interested devs step up, hold a vote for the lead,
and then respect the lead's role in resolving the issue.  Nobody
"owns" a package, but in general we should be careful about stepping
in and overriding maintainers, especially if nobody is interested in
stepping in to take the reins long-term.

Rich

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

Ian Stakenvicius-2
In reply to this post by Joshua Kinard-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/06/14 07:38 PM, Joshua Kinard wrote:
> Can $PATH be configured via our existing eselect tool to
> enable/disable the crossdev paths when needed?
>

Technically it could but not really ; PATH is an environment thing,
AFAIK all eselect could do is trigger the addition or removal of
entries in /etc/env.d/ , but after that happens one would still need
to 'env-update && . /etc/profile' to get the changes.

Similarly I don't think using an eselect tool to bring the crossdev
tools into the default path (via symlinks) is a great idea either; yes
it'd allow users to un-eselect the crossdev tools when errors occur,
but the errors would still occur every time a user forgets to do this
first.

It would be easier to update PATH yourself manually in the shell, I
expect; perhaps a quick utility could do that for you (maybe opening
up a crossdev-ready subshell) so you don't have to remember the path.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlOgQcwACgkQ2ugaI38ACPB17AEAk0NFZ2Q5B19C0LYxHQ8aocmh
XQN9gaSEihGR5xJw6B8BAIsnZFtHxqk5kBwfKgG0MIcdfttGncSfgT6esKTCPf09
=DBJn
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

hasufell
In reply to this post by Rich Freeman
Rich Freeman:
> On Tue, Jun 17, 2014 at 8:30 AM, hasufell <[hidden email]> 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.

12345