From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 376CA13877A for ; Tue, 17 Jun 2014 13:53:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 72A2FE0B19; Tue, 17 Jun 2014 13:53:46 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6E279E0AFB for ; Tue, 17 Jun 2014 13:53:45 +0000 (UTC) Received: from 127.0.0.1 (tor-exit0-readme.dfri.se [171.25.193.20]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id 123E234003C for ; Tue, 17 Jun 2014 13:53:42 +0000 (UTC) Message-ID: <53A04859.2060209@gentoo.org> Date: Tue, 17 Jun 2014 13:53:29 +0000 From: hasufell Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference References: <53208139.2040509@gentoo.org> <1660834.UE1ARX9orZ@vapier> <20140327084108.GA3654@rathaus.eclipse.co.uk> <31757180.gTPZtqku3h@vapier> <20140330095348.GA18419@rathaus.eclipse.co.uk> <539E03A9.3010109@gentoo.org> <539E0563.3080302@gentoo.org> <539EF323.7020208@gentoo.org> <1402944163.8309.2.camel@oswin.hackershack.net> <539F462E.6050905@gentoo.org> <20140616214257.096c93fc@marga.jer-c2.orkz.net> <539F49C2.6090008@gentoo.org> <539F4DFA.7020706@gentoo.org> <539F5288.1000000@gentoo.org> <539F5AB5.7000006@gentoo.org> <539F6B3C.7030807@gentoo.org> <539F8000.5080804@gentoo.org> <539F9E41.9050505@gentoo.org> <539FA536.3010401@gentoo.org> <53A034F4.2000900@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 0554ea10-a738-4a06-9bf4-5f03de702283 X-Archives-Hash: 9cbde6e0b7d272fd1e59b35202a8f395 Rich Freeman: > On Tue, Jun 17, 2014 at 8:30 AM, hasufell 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.