On Mon, 16 Jun 2014 16:27:19 -0400
Ian Stakenvicius <[email protected]> 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
