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 1LgPX1-0003rX-6R for garchives@archives.gentoo.org; Sun, 08 Mar 2009 20:23:31 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3AEEAE0439; Sun, 8 Mar 2009 20:23:30 +0000 (UTC) Received: from mailfilter4.ihug.co.nz (mailfilter4.ihug.co.nz [203.109.136.4]) by pigeon.gentoo.org (Postfix) with ESMTP id B54BFE0439 for ; Sun, 8 Mar 2009 20:23:29 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQCAHvGs0l2XMmS/2dsb2JhbAAIlX+8aoQFBoQh X-IronPort-AV: E=Sophos;i="4.38,325,1233486000"; d="scan'208";a="153937317" Received: from 118-92-201-146.dsl.dyn.ihug.co.nz (HELO [10.1.1.3]) ([118.92.201.146]) by smtp.mailfilter4.ihug.co.nz with ESMTP; 09 Mar 2009 09:23:28 +1300 Message-ID: <49B42930.50208@gentoo.org> Date: Mon, 09 Mar 2009 09:23:12 +1300 From: Alistair Bush User-Agent: Thunderbird 2.0.0.19 (X11/20090228) 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] x-modular.eclass: A modified approach to EAPI support References: <20090306205729.GC22566@comet> <18866.17225.129454.389648@a1ihome1.kph.uni-mainz.de> <8b4c83ad0903070206l78e79fefl2247371c9a5a6376@mail.gmail.com> In-Reply-To: <8b4c83ad0903070206l78e79fefl2247371c9a5a6376@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 974e1939-9d48-4299-83de-292e07e0e1b7 X-Archives-Hash: b83c35e4e562314b8b91af480a64334f Nirbheek Chauhan wrote: > On Sat, Mar 7, 2009 at 3:20 PM, Ulrich Mueller wrote: >>>>>>> On Fri, 06 Mar 2009, Donnie Berkholz wrote: >>> Any thoughts? >>> + *) >>> + die "Unknown EAPI ${EAPI}" >>> + ;; >> Is is safe to assume that an unknown EAPI will provide a "die" >> function? >> > > If we get all Ciaran-ey about that, then we can't even assume the > existence of a case statement in some future version of bash (which is > required by some EAPI) > > I think in these cases we just have to use common sense. If a function is deprecated or "known to be 'on the way out'" then using them would obviously be a bad idea. On the other hand even if they are used, surely someone would test an ebuild and discover this case pretty quickly.