From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1N5o5t-0003sA-AU for garchives@archives.gentoo.org; Wed, 04 Nov 2009 22:12:45 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8789BE08F0; Wed, 4 Nov 2009 22:12:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 3FCD0E08F0 for ; Wed, 4 Nov 2009 22:12:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id CB97265267 for ; Wed, 4 Nov 2009 22:12:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 required=5.5 tests=[AWL=-0.700, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ql1FBmCV5UFa for ; Wed, 4 Nov 2009 22:12:36 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 4881D675CF for ; Wed, 4 Nov 2009 22:12:34 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1N5o5f-00026K-4W for gentoo-dev@gentoo.org; Wed, 04 Nov 2009 23:12:31 +0100 Received: from liten.csbnet.se ([95.80.45.98]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Nov 2009 23:12:31 +0100 Received: from xake by liten.csbnet.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Nov 2009 23:12:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Peter Hjalmarsson Subject: [gentoo-dev] Re: FEATURES use or misuse? Date: Wed, 04 Nov 2009 23:12:05 +0100 Message-ID: <1257372724.5846.26.camel@lillen.dodi> References: <200911031648.04090.patrick@gentoo.org> 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: liten.csbnet.se In-Reply-To: <200911031648.04090.patrick@gentoo.org> X-Mailer: Evolution 2.28.1 Sender: news X-Archives-Salt: a18e2fe8-7cc3-4910-b419-623bddfb27df X-Archives-Hash: a93c9579fc38ef64eb3a64465e655c82 tis 2009-11-03 klockan 16:48 +0100 skrev Patrick Lauer: > Hi there, >=20 > All of these bugs were for the use of the FEATURES variable in ebuilds, w= hich=20 > is a very convenient thing to work around issues.=20 > For example known failures with FEATURE=3D"distcc" or funky things like t= est=20 > failures with FEATURES=3D"userpriv" and so on. All other methods of expre= ssing=20 > that are much more verbose and inherently sucky. I ask myself if what we really want is many different and strange approaches to handle FEATURES? Would it not be better to actually expand some eclasses to be able to say something about your build environment? I mean where the checks for "userpriv" is needed also prefix will fail, because AFAIK it can be used to build and install programs in an non-root environment? Or if you just test an ebuild and runs it as your user? So would it not just be better to have a check for which privs the user has so it covers more fields? For "ccache" and for "distcc" would it not be better to expand toolchain-funcs so you can have a function like "tc-getCC" from which you can get that sort of information? Also if the ebuilds does not already have a comment about it, do not forget to comment on why these checks are there, and why they are a must (i.e. a broken buildsystem should be fixed, not worked around - while tests that are designed to run as root should not be run as a user even if in the best of worlds all testsuits should test and skip those tests themselves). I would not like to see a new kind of hell where when something is broken it is not fixed properly, but in a strange ways worked around in ways that does not always work. qemu and kvm is good examples on how NOT to do this these with regards to hardened. qemu (which kvm apparently has used as a template) has a broken build system (it does not link with CFLAGS, only LDFLAGS, which is something that also the gcc devs say you should not if you want a predictable result), and it also invokes filter-flags at the wrong place in the ebuild (hint: int should be invoked before the command that sets the CFLAGS, in this case ./configure and not after like in these ebuilds). Instead it has some strange logic to unset/change the GCC_SPECS which if it ever worked certainly does not anymore (bugs filed for both, qemu bug is really old, but very noisy, bug for kvm has been open for about an week which the qemu maintainer may want to check out, with a clean patch of one added sed a move of filter-flags and the removal of the whole src_compile block to make the ebuild install something which (in case of qemu) actually build, and does not segfault as soon as it uses a bit softmmu).