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 F2F4A1387FD for ; Sun, 8 Jun 2014 14:38:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D54BDE0893; Sun, 8 Jun 2014 14:38:48 +0000 (UTC) Received: from a1www.kph.uni-mainz.de (a1www.kph.uni-mainz.de [134.93.134.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 14E1EE0887 for ; Sun, 8 Jun 2014 14:38:47 +0000 (UTC) Received: from a1i15.kph.uni-mainz.de (a1i15.kph.uni-mainz.de [134.93.134.92]) by a1www.kph.uni-mainz.de (8.14.7/8.14.7) with ESMTP id s58EcjBb022005 for ; Sun, 8 Jun 2014 16:38:45 +0200 Received: from a1i15.kph.uni-mainz.de (localhost [127.0.0.1]) by a1i15.kph.uni-mainz.de (8.14.8/8.14.2) with ESMTP id s58Ecie3015364; Sun, 8 Jun 2014 16:38:44 +0200 Received: (from ulm@localhost) by a1i15.kph.uni-mainz.de (8.14.8/8.14.8/Submit) id s58EchHS015360; Sun, 8 Jun 2014 16:38:43 +0200 Message-ID: <21396.30067.503349.626165@a1i15.kph.uni-mainz.de> Date: Sun, 8 Jun 2014 16:38:43 +0200 To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] EAPI6 Features In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-pc-linux-gnu) From: Ulrich Mueller 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 Content-Type: multipart/signed; boundary="pgp+signed+9lK+Lab0IZUfyHO"; micalg=pgp-sha256; protocol="application/pgp-signature" X-Archives-Salt: 5673fa16-1e67-44a0-a6c0-77fb373a49c3 X-Archives-Hash: 6c166c3b1e83bb3a83a6254748449dee This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --pgp+signed+9lK+Lab0IZUfyHO Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >>>>> On Sun, 8 Jun 2014, Rich Freeman wrote: >> b) failglob in global scope >> Bug #463822 > 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. Any specific example of a side effect that you have in mind? I believe that there are none in global scope, but maybe we shouldn't extend the feature to function scope. >> 4. Features rejected from EAPI 5 > Ok, I suspect we're going to spend about 95% of the time on these. Yes. ;-) >> a) Patch applying function in package manager >> Bug #463768 >> - 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. This more or less agrees with the status of the discussion: https://bugs.gentoo.org/show_bug.cgi?id=463768#c32 We haven't decided yet if there should be autodetection, but I'd also prefer a -p1 default without autodetection. There's always epatch if you need anything more fancy. >> b) User patches >> Bug #475288 >> - 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. IMHO the package manager shouldn't perform any operations between src_* phases, outside of phase functions. Therefore, the user patch function should be called either from src_prepare, or from a phase function (src_userpatch?) newly introduced. I'd strongly dislike a new phase function, but conceptionally, it would still be much cleaner than doing some magic after src_prepare. My suggestion would be to add the user patch function to default_src_prepare, plus a policy that the function must be called if an ebuild (or eclass) contains an explicit src_prepare(). The latter could be enforced by repoman. >> c) EJOBS variable >> Bug #273101 >> - 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. I don't have a strong opinion about this one. However, my general advice would be not to impose work on PMS and package manager teams, for features that nobody is pushing any longer. >> d) Source eclasses only once >> Bug #422533 > 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. Right, discussion has died down. Many eclasses now use a mechanism equivalent to the one in C header files, which seems to do the job. >> e) HDEPEND: host dependencies for cross-compilation >> Bug #317337 > 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=""? We did RDEPEND=${DEPEND} once and it was a mistake. So I think default HDEPEND should be empty. Ulrich --pgp+signed+9lK+Lab0IZUfyHO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJTlHVeAAoJEMMJBoUcYcJzyEMIAJ5qmPId9nyafhFHmpDf5xu9 efKqRm9ivPtIgxW3nPHC5yFf17oBkXSOc2tIr3eXlaSoZT234z3zZr/T27ngkIRA Esbgv8R8ydYQKc+bMAayGNNKf2yEn5KKBU2NgEfzofWfutFEwUvKlGBaZVqanwsO u1LGfrDBHb/zry0IltjMJ0wxZIld+xZVsmeUsQ9PIdfnPAdaovRbE7rd5ykvGVSE u00twPlygxpvjsBt1Vt0tnVmPMc6ZZj8QksmjM9qm4R2/1tcnUY4Z9CwlChPOtCQ HcSSVCF8kPkZRm9ufsF3K9KV72cFrpTdS8Hzt8QaQl22pqsvYJ38Nj8QFgUhz4E= =PqMU -----END PGP SIGNATURE----- --pgp+signed+9lK+Lab0IZUfyHO--