From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 71787138010 for ; Wed, 12 Sep 2012 04:56:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8460421C00C; Wed, 12 Sep 2012 04:55:43 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 560C421C003 for ; Wed, 12 Sep 2012 04:54:42 +0000 (UTC) Received: by ieak12 with SMTP id k12so2424900iea.40 for ; Tue, 11 Sep 2012 21:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JRlf6dNcmvz5f4ykhvt0gpGSfTsS26SUhftw6qeWHnM=; b=kZ6QkdDEucv5K3mf0tPchEL6Xj+y0lbhk/qI503AT8mH8Gfi0Cj17q5Mhu0042ET78 jcQ/5pCQda9eDp5KYzjGMvnwTXz8J23cEULoEnPKpYP8H7CKQGUct/RTCiExjGTSdHhI ZbYYjUQ597TlM9tUn6ki0Y+QSyQ8rB8mUO2TUcVA8y+Z6ZM3fHcHGksZAYvDTLkgWwZ6 RW1ajSy5qjWG1+lJHiMp3dkHrDAjp8+MA6eWJkUjqpuv8jZzo1kINHnxWtZaYlc17gGk XfkS5U3+LLfgHswDDEc6BL58b/baOciqk695r2X3K8uoF/f8YfRNk/Hf2GAwgHeulieF EcYg== 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 Received: by 10.50.181.201 with SMTP id dy9mr2979027igc.61.1347425682459; Tue, 11 Sep 2012 21:54:42 -0700 (PDT) Received: by 10.64.94.198 with HTTP; Tue, 11 Sep 2012 21:54:42 -0700 (PDT) In-Reply-To: <20120911161344.56860db0@pomiocik.lan> References: <50411874.4060204@gentoo.org> <20120831214611.088b3f50@googlemail.com> <50469795.2070901@gentoo.org> <20120906081145.GC18495@localhost> <20120911161344.56860db0@pomiocik.lan> Date: Tue, 11 Sep 2012 21:54:42 -0700 Message-ID: Subject: Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5? From: Brian Harring To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= Cc: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: f32c7ebf-0570-447c-982d-7415c114d8b5 X-Archives-Hash: 23c89cf8d31a3f51b1ca8c9e7759831c On Tue, Sep 11, 2012 at 7:13 AM, Micha=C5=82 G=C3=B3rny = wrote: > On Thu, 6 Sep 2012 01:11:45 -0700 > Brian Harring wrote: > >> A compatibility hack that stacks them is strongly advisable; >> something akin to the following: >> >> Literally, we do the following: >> inherit() { >> if eapi blah; then >> local DEPEND PDEPEND RDEPEND >> >> else >> >> fi >> >> if eapi blah; then >> local _deps=3D( ) _x >> for _x in DEPENDENCIES DEPEND RDEPEND PDEPEND; do >> [ -n "${!_x}" ] && deps+=3D( "${!_x}" ) >> done >> [ ${#deps} -ne 0 ] && DEPENDENCIES=3D"${deps[*]}" >> unset DEPEND RDEPEND PDEPEND _x _deps >> >> else >> >> fi >> } >> >> Via that, we eclasses that are pure DEPENDENCIES eapi wise, just set >> the DEPENDENCIES directly; those that have to support multiple eapi's >> (aka, every fricking eclass that exists right now) can just use the >> old form, shifting into the new form as things progress. > > If we decide to go with a such a hack, then we either have to support > it indefinitely, or to decide to drop the support in some further EAPI. It's a transitional hack; we support it as long as we need the transition coverage. Meaning if by EAPI7, everyone is using EAPI5 and up (or by EAPI7 it's basicaly insane to try and support 0,1,2,3,4,5,6,7), we drop the transition code in EAPI8. This is no different to how RDEPEND/DEPEND autosetting was phased out. > If we go for the latter, then it's just delaying the ugly conditional > eclasses will have to suffer at some random point in the future. Hate to say "na uh", but... na uh. The point is as long as an eclass has to support older EAPI's, they can use set DEPEND/RDEPEND and it would work fine. If the eclass needs the newer depends types (hdep, fdep, whatever) for something, it levels an EAPI check, and then sets DEPENDENCIES. Meanwhile, until it moves it's minimal EAPI to one requiring DEPENDENCIES, they can use the old syntax and have it stacked. Basically, either we can have git.eclass (for example) doing: if has $EAPI 0 1 2 3 4; then DEPEND=3D">=3Ddev-util/git-1.6" else DEPENDENCIES=3D"dep:build? ( >=3Ddev-util/git-1.6 )" fi Or, as long as it's suppporting EAPI's 0 1 2 3 4 and the transition is still enabled for the actual EAPI it's being used in... DEPEND=3D">=3Ddev-util/git-1.6" Doing this means no eclass code has to maintain EAPI5 dependencies code and =3DEAPI5, they convert to DEPENDENCIES syntax as they go/have spare cycles. Bluntly, this approach makes transition pretty painless for the vast majority of the tree. In the grand scheme of things, this is actually one of the simplest/cleanest migration EAPI will see I suspect. There really isn't a sane argument to be made against this beyond "screw it, just make the devs convert immediately and damn the costs" (which I don't view as sane). Either way, strongly get the feeling you're arguing purely because it had the term DEPENDENCIES in it... ~harring