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 AC019139694 for ; Fri, 28 Apr 2017 13:25:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5C2CEE0E66; Fri, 28 Apr 2017 13:25:40 +0000 (UTC) Received: from smtp.gentoo.org (mail.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 00DA5E0D90 for ; Fri, 28 Apr 2017 13:25:39 +0000 (UTC) Received: from katipo2.lan (unknown [203.86.205.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id 981783416DF for ; Fri, 28 Apr 2017 13:25:38 +0000 (UTC) Date: Sat, 29 Apr 2017 01:25:07 +1200 From: Kent Fredric To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Providing consistent means to enable tests requiring Internet access Message-ID: <20170429012507.0deaf24c@katipo2.lan> In-Reply-To: <1493302453.1189.1.camel@gentoo.org> References: <1493302453.1189.1.camel@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: multipart/signed; micalg=pgp-sha256; boundary="Sig_/diITk0WSs+j2ff1r7rdKAaQ"; protocol="application/pgp-signature" X-Archives-Salt: 691d1928-9b2a-49f2-9057-46bb00f38e15 X-Archives-Hash: ea2c3202e8e70902bd91e1048b859eb3 --Sig_/diITk0WSs+j2ff1r7rdKAaQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 27 Apr 2017 16:14:13 +0200 Micha=C5=82 G=C3=B3rny wrote: > What do you think? Any other ideas? I personally think that "test" being exposed as a useflag is a hack that sh= ouldn't be perpetuated further. I'd rather have the ability to check for the flag the same way as we check = for arch, but without necessitating that the test driver use flags are exposed visibly even to people who aren'= t using FEATURES=3Dtest Similarly, there's irritation derived from having USE flags that *only* per= tain to tests, because they turn into null-options when toggled, or pointless REQUIRED_USE rubbish. I'd rather we have something that side-steps the need for futher USE flag a= buse, and made testing flags only visible to users who were *actually* doing testing. Something akin to USE_EXPAND but just for test flags seems pertinent. Because there's plenty of *other* classes of testing options that we might = want in the future. For instance, regression tests, which by necessity create circular dependen= cies, *should* be a visible option. And I can imagine something like TESTS=3D"-* gentoo" being something that c= ould eventually come into existence, which would be a flag that toggled on gentoo supplied tests. Large complex tools like databases also need graduated control of tests, be= cause the current approach is very much "all or nothing" most of the time, when i= n reality: -> I want to run *some* sensible tests for all packages -> But I don't want to be running test suites that could run for 50+ hours = ( sys-libs/db ) But for people who don't use FEATURES=3Dtest, none of those toggles should = be something they even have to know about, the flags should simply evaporate without it. And TEST-specific flags should be discouraged from RDEPEND, just like "test= " is. TEST-specific flags in DEPEND is also somewhat dubious when it comes to --w= ith-beps=3Dy=20 I think in the long term, I'd want a TDEPEND or something instead. I know you're vying for "a small incremental step that just fixes this one = niche", but this is basically a problem that's been known ( at least by me ) for ma= ny years, and we're in growing need of a real solution, not a small incremental hack = that is a disservice to the future we know exists. --Sig_/diITk0WSs+j2ff1r7rdKAaQ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPZazbI/qrFT1o9rn6FQySxNmqCAFAlkDQsQACgkQ6FQySxNm qCAP5hAAo/mJVRRJxDxB9AMMkgp+nYK0FV2L4o9+AzhF+GAM2HaV2NEg9RN5hENS oXlHXuKDqPERuT7xK433YKDvxaqpNJ/S9UcyLwRIkvVjaogphOfpnRZYmaHaABmg xEWWsG1ITYidchstFL8fMjMEEHX9b7Bjp8l889uEUxWVEAKZSCW0TZt+Xkgaiej5 qPDS6Do4OinogPpvFAGV5omAyguBnG1VCtjiR2uta7ubeKz7aEMkaRdkIolsaKDD fxn2u3wVHZMScaZK5Ep6J1g9Ruh90UOsn0lz3LVKRLltKFdsqUv3QmAqONVtiSHA H7ZGmaLhNVJbbymUpwqGQFrFRq8tE4tcD493IZX/OSSWJzOEgzjgmUP5v155RhPQ UY+feafub9OOkYGAaH654T3XOM3KP5CrsqxrOQlBOy+r6xZt6GSVcLpW4OsIOxhP pCDG9u0Hlif0+umlu1TAdYiAK+LzZAThGW9HmWbKR4eOQblAOtMPFOYAVn3yXiGW /nk4dTuN/ZoPu1YxV718ooEGCvPtmqhRtHS9AsASn1eqaJqmKFAjyILAFzMrX95c YZ98bNUfDx3eHDmMVLbBMx5/RpTu5xVkB6kmdzp7TiaW2EO/wVPAZEEsJHiauN2l f43rIDYq9bVj5MBJH91Ofg5YrGAd5nL4Ic2Yt/lJGasGpFO3iBA= =zMpL -----END PGP SIGNATURE----- --Sig_/diITk0WSs+j2ff1r7rdKAaQ--