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 <hasuf...@gentoo.org> 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 ku...@gentoo.org 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
