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 AAFB21387FD for ; Sun, 8 Jun 2014 13:04:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 32501E0ACF; Sun, 8 Jun 2014 13:04:22 +0000 (UTC) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8F239E0A9A for ; Sun, 8 Jun 2014 13:04:21 +0000 (UTC) Received: by mail-ve0-f171.google.com with SMTP id jz11so1257162veb.16 for ; Sun, 08 Jun 2014 06:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=UBUmfNAgHxdXZZ30W4BIVDyDVCwx6vftQxJ41EEoMdc=; b=Yf7eHsei1/muWVOV5fSX6FV9gfsczAG1kwOf7MkNqEDm6tKpOyW9wO28Y7H6GYBJ8s 8X00Cd91nh3rYLIi4qXFBvVKwCRXugY+e4s4OGmTaGjVvI5xXNDlFjvs+IZ7pd8wKjVu QMnMRZpWqyi0O79pXIVn9buoLoW4/eL5oyyrDyeLL8XNvRJ1TZTsohFbuHMd9rJyXtJM EporvZ4ecJksDOwK+5HHVkUKtv6rOBjBBOUVw6AW6798cUofvMv82SKsw3ozGjzvg/S3 FrkPTpRRUWKC6jtkd3E2C9c1SQSr0sCZIDZrvOPH4Q9fYqTNgYgiwIsC/S7LsCIbM4T5 ntEA== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.53.12.229 with SMTP id et5mr16630882vdd.32.1402232660606; Sun, 08 Jun 2014 06:04:20 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.30.227 with HTTP; Sun, 8 Jun 2014 06:04:20 -0700 (PDT) Date: Sun, 8 Jun 2014 09:04:20 -0400 X-Google-Sender-Auth: w9Js5beamlLSmOBA8UCIMKol7xo Message-ID: Subject: [gentoo-project] EAPI6 Features From: Rich Freeman To: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 7822a0d9-e7a8-4219-b97d-1c303f2a95ae X-Archives-Hash: 6f7d93bd46bc03b60cbe9eec3a903d1d Most of the proposed EAPI6 features seem ripe for acceptance, but I figured I'd comment on a few here in case others want to weigh in. On Thu, May 29, 2014 at 9:56 AM, Ulrich Mueller wrote: > > b) failglob in global scope > Bug #463822 [13] I'm a bit concerned that this one could be a cure worse than the disease - unintended side-effects/etc. A repoman check seems a lot less likely to cause problems. Part of me wonders that there is a trend towards using bash as a general-purpose programming language. Just about any higher-level data/control/etc structure in bash tends to be cumbersome. Really all the non-fatal die stuff is nothing more than exception handling in a language not designed for exception handling, but that at least seems manageable. > > 4. Features rejected from EAPI 5 Ok, I suspect we're going to spend about 95% of the time on these. Few have much progress since the last time they were rejected. > > a) Patch applying function in package manager > Bug #463768 [14] > - Needed for 2d) and 4b) > - This will duplicate epatch() from eutils, in simplified form. > - Name "eapply" has been suggested. > My two cents. Keep an eclass for the fancy stuff, but move into the EAPI a few basic patch functions: 1. Application of a patch file, defaulting to -p1, allowing override of -p level, but without auto-detection. 2. Application of a directory full of patch files in lexical order, again supporting override of -p level without auto-detection. I'm not a big fan of either auto-detection or forcing patch re-writes to be -p1 always. > b) User patches > Bug #475288 [15], PMS wording [16] > - Needs 4a) > - Current wording of the spec requires that every ebuild must > include a call to the function in src_prepare, which is > controversial. > - Names "apply_user_patches" or "eapply_user" have been suggested. > I'm generally fine with it (we can bikeshed the name to death later), but is there any reason to not just simply apply the patches after src_prepare is done and not make maintainers call it? If we're concerned about sequencing with other activities in src_prepare then that is fine - I don't have a big problem with it being a fatal error if it doesn't get called. > c) EJOBS variable > Bug #273101 [17], gentoo-dev discussion [18] > - Discussion was in 2008. Is there (still) consensus? > Assuming anybody still wants to implement this, I see no reason to keep bikeshedding this. EJOBS fits the bill. The only thing that might be worth noting is that distcc users may have an interest in distinguishing between gcc jobs and everything else. I once messed with dictcc with very high job numbers and it worked great when make hit a directory full of .c files, and not so great when make/ant/whatever tried to run 50 instances of java in parallel. > d) Source eclasses only once > Bug #422533 [19], gentoo-dev discussion [20] > Does anybody still want this included? It seems to me like the list discussion was leading in a different direction, but it isn't 100% clear to me if this is the case. > e) HDEPEND: host dependencies for cross-compilation > Bug #317337 [21] > It isn't 100% clear to me which of the 14 proposed solutions in that bug is the final answer, but I think it is DEPEND becomes target depends, and HDEPEND is introduced as host depends. Is the final intent that if HDEPEND isn't defined, then HDEPEND=DEPEND, or does HDEPEND=""? The ones I didn't mention seem basically fine as-is, or with the tweaks already mentioned in the bugs. Rich