From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 43903139694 for ; Mon, 5 Jun 2017 07:55:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E180421C04E; Mon, 5 Jun 2017 07:55:23 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 840D2E0D47 for ; Mon, 5 Jun 2017 07:55:23 +0000 (UTC) Received: from localhost (unknown [IPv6:2a01:e34:eeaa:6bd0:4ecc:6aff:fe03:1cfc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 34F1E33BF1C for ; Mon, 5 Jun 2017 07:55:22 +0000 (UTC) Date: Mon, 5 Jun 2017 09:55:16 +0200 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE) Message-ID: <20170605095516.0b463432@gentoo.org> In-Reply-To: <20170604105938.2b40157f@gentoo.org> References: <1496071993.31087.1.camel@gentoo.org> <20170530092245.681d4aeb@snowblower> <20170530104654.31b89e10@gentoo.org> <20170530095607.1adbc0b8@snowblower> <20170530112518.65b4f9e9@gentoo.org> <22829.24276.295.969060@a1i15.kph.uni-mainz.de> <1496154812.1238.5.camel@gentoo.org> <20170530173340.0b575526@gentoo.org> <1496167898.1335.1.camel@gentoo.org> <20170530204614.61e8e42c@gentoo.org> <1496213717.1164.1.camel@gentoo.org> <20170531093257.23b66f88@gentoo.org> <1496217792.1164.5.camel@gentoo.org> <20170531103819.417c2420@gentoo.org> <1496235892.25038.1.camel@gentoo.org> <20170531193922.477245bb@gentoo.org> <1496257344.25758.1.camel@gentoo.org> <20170601105523.08a9234e@gentoo.org> <1496352685.30502.4.camel@gentoo.org> <20170602132758.50a5f734@gentoo.org> <1496411717.29233.5.camel@gentoo.org> <20170603130000.4f88fb14@gentoo.org> <1496503989.15351.1.camel@gentoo.org> <20170603185835.57741ff0@gentoo.org> <20170604105938.2b40157f@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) 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=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 13577fdf-5a1b-4d0e-8c75-46457f061107 X-Archives-Hash: 070e2d95827068dab76adbbe39c17303 On Sun, 4 Jun 2017 10:59:38 +0200 Alexis Ballier wrote: > Here's a quick n dirty code to play with, based on yours: > https://github.com/aballier/required-use I've run that on the whole tree (considering all ebuilds with non empty REQUIRED_USE), some stats: $ time python3 classify.py requsel Stats: Parse error: 16 Good: 8316 Need topo sort: 140 Cyclic: 57 real 0m2.996s user 0m2.950s sys 0m0.004s Running time is good I think. Parse error is some nested construct not supported by your parser that I have not fixed either. ~2.5% simply need to be reordered. ~0.6% require more clever thinking. Let's have a look at a few of them: sys-fs/cryptsetup-1.7.5 ^^ ( gcrypt kernel nettle openssl ) python? ( || ( python_targets_python2_7 python_targets_python3_4 python_targets_python3_5 python_targets_python3_6 ) ) static? ( !gcrypt ) USE='-* static' is painful: the first ^^ will enable gcrypt, static? ( !gcrypt ) will disable it. Reordering the ^^ so that kernel appears first fixes the cycle. media-libs/mesa-13.0.6 || ( gcrypt libressl nettle openssl ) d3d9? ( dri3 gallium ) llvm? ( gallium ) opencl? ( gallium llvm ) openmax? ( gallium ) gles1? ( egl ) gles2? ( egl ) vaapi? ( gallium ) vdpau? ( gallium ) vulkan? ( video_cards_i965 ) wayland? ( egl gbm ) xa? ( gallium ) video_cards_freedreno? ( gallium ) video_cards_intel? ( classic ) video_cards_i915? ( || ( classic gallium ) ) video_cards_i965? ( classic ) video_cards_nouveau? ( || ( classic gallium ) ) video_cards_radeon? ( || ( classic gallium ) gallium? ( x86? ( llvm ) amd64? ( llvm ) ) ) video_cards_r100? ( classic ) video_cards_r200? ( classic ) video_cards_r300? ( gallium x86? ( llvm ) amd64? ( llvm ) ) video_cards_r600? ( gallium ) video_cards_radeonsi? ( gallium llvm ) video_cards_vmware? ( gallium ) The cycle is mostly due to: $ python3 nsolve.py 'llvm? ( gallium ) gallium? ( llvm )' [...] toposort.CircularDependencyError: Circular dependencies exist among these items: {[gallium]? => [llvm]:{[llvm]? => [gallium]}, [llvm]? => [gallium]:{[gallium]? => [llvm]}} This is something I had overseen when replacing 'a q'_j is some p_i and one of q_1 ... q_m might be false' by only 'a q'_j is some p_i'; it can be replaced without changing anything in the way PM would solve it by "a q'_j is some p_i and the set of {q_j} is not a subset of q' union p'" (that is, {q_i} is not trivially true if the 2nd clause is applied). Extending that, we get those stats: Stats: Parse error: 16 Good: 8325 Need topo sort: 146 Cyclic: 42 real 0m1.575s user 0m1.563s sys 0m0.012s Now we seem to get only valid warnings (I have not checked them all though): sys-firmware/seabios-1.10.1: debug? ( !binary ) !amd64? ( !x86? ( binary ) ) USE="debug -amd64 -x86" ? sci-libs/ceres-solver-1.11.0: test? ( gflags ) sparse? ( lapack ) abi_x86_32? ( !sparse !lapack ) USE='-* sparse -lapack abi_x86_32' shows a conflict between the last 2 clauses. Better write: test? ( gflags ) !abi_x86_32? ( sparse? ( lapack ) ) abi_x86_32? ( !sparse !lapack ) which makes the test work mail-mta/exim-4.89 dane? ( !gnutls ) dmarc? ( spf dkim ) pkcs11? ( gnutls ) spf? ( exiscan-acl ) srs? ( exiscan-acl ) USE="dane pkcs11" ? sci-libs/hdf5-1.8.18: threads? ( !cxx !mpi !fortran !hl ) fortran2003? ( fortran ) USE="threads fortran2003" ? I'll let you play with it, but for me it seems this would work quite nicely. Alexis.