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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9452C158094 for ; Sat, 16 Jul 2022 20:20:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BF6512BC022; Sat, 16 Jul 2022 20:20:09 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5517D2BC001 for ; Sat, 16 Jul 2022 20:20:09 +0000 (UTC) From: Ulrich Mueller To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Proposal to undeprecate EGO_SUM In-Reply-To: (William Hubbs's message of "Sat, 16 Jul 2022 14:35:46 -0500") References: <20220613074411.341909-1-flow@gentoo.org> <1a712a66f55e241ce6b6084eb19e1f34@sinustrom.info> <20585037-1d3c-2b2d-90a3-b9ab74fa78aa@gentoo.org> <1d2db3c2-e002-4f47-ba6e-f1927a2622d8@gentoo.org> <17acb60d-4f13-fad9-702c-64cad71a3c05@gentoo.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) Date: Sat, 16 Jul 2022 22:20:01 +0200 Message-ID: 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Archives-Salt: 88b5e5dc-cc7b-4e1e-a03b-50f531bddf1c X-Archives-Hash: d4fe44d414a9a876b98203aebc0367eb --=-=-= Content-Type: text/plain >>>>> On Sat, 16 Jul 2022, William Hubbs wrote: > I could force this in the eclass with the following flow if I know how > to tell if the ebuild inheriting it is in the main tree or not: > # in_main_tree is a place holder for a test to see if the ebuld running > # this is in the tree > if [[ -n ${EGO_SUM} && in_main_tree ]]; then > eqawarn "EGO_SUM is not allowed in the main tree" > eqawarn "This will become a fatal error in the future" > fi > The only question is, is there a way to reliably tell whether or not > we are in the main tree? An eclass has no legitimate way to find out in which repository it is. The rationale is that users should be able to copy ebuilds and eclasses to their local overlays, and they should work there in the same way. There is an internal (and undocumented) Portage variable, but that shouldn't be used. Ulrich --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmLTHXEPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4umPUIANIWhMa1/GUtDw4ezTu0ms/2k80qDbvu4c9F FOF+i5fs14ibfnoKIa2P8iX/uOEmSWfW0pvWQSL3XMHtXdVvMOVu86coTpipBdvN WAgHTKWo/0J1jM1nWTwk2GfPdPyLjDmeDTYfUztd+UnTNsHWPCCKLB6fSXuFqYYk 7xxUWHXn125x/UxwCqRRRlxr/QM9zw0H66i9hkCVdRk0zN2sofCdwFZ0LEtwzejs QtpDO+7Q3O6dzthFw2M5plbyKa73wTTsNn/pNLS+gQPuXY556tqmS7Y8XtB8BmBB Rr24FePSM6ufFy1FMZB00CmW81WnXlGc34NQI+28xIpP/Ffa/uM= =xy9N -----END PGP SIGNATURE----- --=-=-=--