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 1RKeEC-0004Tz-8c for garchives@archives.gentoo.org; Sun, 30 Oct 2011 22:51:44 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A43FA21C0F9; Sun, 30 Oct 2011 22:51:35 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 75F2B21C0D0 for ; Sun, 30 Oct 2011 22:50:52 +0000 (UTC) Received: from [192.168.168.169] (dyn-199-173-dsl.vsp.fi [83.146.199.173]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ssuominen) by smtp.gentoo.org (Postfix) with ESMTPSA id 5AB821B400B for ; Sun, 30 Oct 2011 22:50:51 +0000 (UTC) Message-ID: <4EADD4C2.5080806@gentoo.org> Date: Mon, 31 Oct 2011 00:50:42 +0200 From: Samuli Suominen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20111014 Thunderbird/7.0.1 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] portability.eclass: dead egethome, egetshell, is-login-disabled funcs ? References: <4EADD0CF.70601@gentoo.org> <4EADD18F.9050300@gentoo.org> In-Reply-To: <4EADD18F.9050300@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 4ac993c6-9645-4e66-a9c0-c269b0c8f745 X-Archives-Hash: d22c3c1e3602cf7ad8ad6da11f5600b1 On 10/31/2011 12:37 AM, Markos Chandras wrote: > On 10/30/2011 10:33 PM, Petteri R=E4ty wrote: >> On 27.10.2011 2.40, Mike Frysinger wrote: >>> i can't see any ebuild/eclass using egethome, egetshell,=20 >>> is-login-disabled from portability.eclass. anyone have a reason >>> for keeping these before i punt them ? -mike >>> >=20 >> Breaking overlays. Isn't the standing policy still to not break=20 >> backwards compatibility as long as an eclass exists? >=20 >> Regards, Petteri >=20 >=20 > We have no have direct control on overlays. It is up to maintainers to > ensure that their packages work with portage eclasses or they can have > their own eclasses locally. There could be an deprecation warning that the functions are going away to be nice with overlay maintainers but there is no requirement for such thing far as I'm aware. Punt away. - Samuli