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 14784138010 for ; Wed, 3 Apr 2013 09:14:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 49361E0D4C; Wed, 3 Apr 2013 09:14:28 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0EB55E0D43 for ; Wed, 3 Apr 2013 09:14:26 +0000 (UTC) Received: from pomiocik.lan (87-205-60-160.adsl.inetia.pl [87.205.60.160]) (using SSLv3 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 6D8ED33DC0A; Wed, 3 Apr 2013 09:14:25 +0000 (UTC) Date: Wed, 3 Apr 2013 11:14:37 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: Gentoo Developer Mailing List Subject: [gentoo-dev] How shall we name the EAPI 6 patch applying function? Message-ID: <20130403111437.4c1e0aa6@pomiocik.lan> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) 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 Content-Type: multipart/signed; micalg=PGP-SHA512; boundary="Sig_/AWzFb27idBRUbcsfO0haN3L"; protocol="application/pgp-signature" X-Archives-Salt: f150fcbe-239b-459c-b1ed-285daa49be83 X-Archives-Hash: 55660291d80b8462d7419e0991f44281 --Sig_/AWzFb27idBRUbcsfO0haN3L Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello all, Wrt bug #463692 [1] we'd like to add a default src_prepare() in EAPI 6, with PATCHES array and user patches support. For that reason, I've requested in bug #463768 [2], that the function used to apply the patches would be public -- so that users and eclasses could use it consequently. After some discussion on the relevant bug we came to the conclusion that the epatch function is relentlessly bloated. It provides a lot of features which are either already discouraged by its maintainer (arch-prefixed patches), result in widespread QA issues (compressed patch support) or is just too hard to implement reasonably. For that reason, the new function will most likely support the following: a) patch files can be specified directly or through a directory in which *all* files will be applied in lexical order, b) patches will be applied with -p1 unless overrode via direct arguments to patch applying function. Rationale will follow. Since that functionality is very limited compared to the epatch function, we will keep the old one in the eclass for anyone really needing it. However, we need a name for the new function. Therefore, I ask you: how should we name the new (and simpler) patch applying function which will be provided in EAPI 6? [1]:https://bugs.gentoo.org/show_bug.cgi?id=3D463692 [2]:https://bugs.gentoo.org/show_bug.cgi?id=3D463768 Please note that the following rationale is assembled mostly from my opinion and understanding of the others. Please do not take is as an official Gentoo statement. Short rationale: 1) automatic -p* support has seen most effort to keep in the spec. However, there are a few important issues with it which outweigh the usefulness of it: * inability to know what intended patchlevel was can result in patches being applied to wrong files (e.g. when patch stops to apply to the intended file or start to apply to an unintended file with a lower patchlevel). * the patches stored in the tree can't be easily reused upstream or by users since 'epatch' is limited to ebuild scope. * the current implementation of epatch results in hard-to-read error output (you have to grep for the 'most proper' run). This also implies that due to a new QA policy, Gentoo tree will consist only of patches adjusted to be used with '-p1'. If nobody steps up earlier, I will write a tool to fix patches to proper patchlevel. 2) compressed patch support is likely the most misused feature in epatch. This is because in the most cases it was used: * (in Sunrise overlay) to apply compressed patches from ${FILESDIR} -- where storing compressed files there is a violation of QA policy. * to apply compressed patches from ${DISTDIR} -- when src_unpack() has uncompressed the patches to ${WORKDIR} already. Considering that the most compressed patches will either be downloaded as compressed files or compressed archives, the responsibility for unpacking them will fall on src_unpack(). Therefore, we believe that there's no need for additional layer of complexity here. 3) support for directories was one of the most obfuscated features of epatch. It included a number of adjustment variables like EPATCH_SUFFIX, EPATCH_FORCE (where nobody could guess its meaning), EPATCH_EXCLUDE and the discouraged arch-prefixed patches. I've taken a quick grep of the Gentoo ebuild tree and the Gentoo patch tree, and it seems that: * only sys-libs/glibc seems to be still using arch-conditional patching. * most of the patch directories consist of files prefixed by ordering number, suffixed by either '.patch' or '.diff'. * some of the patch trees use Debian-style patches. That is, randomly named files with 'series' file determining the order of applying. We've chosen the common solution which will work correctly for most of the ebuilds with no need for additional control variables. Other cases will either need to use globs to choose files directly, or the eclass-defined epatch function. I hope I covered all the main points. If I missed something, please let me know. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/AWzFb27idBRUbcsfO0haN3L Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQJ8BAEBCgBmBQJRW/MDXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKFWYP/j6lTKYiCiSWMZYAIV2oXoHn 0rgFvkShImpvjYJIeTx6Pfe4dRDMK43WMrGZW5WE0BTIAg3dULTAeTpGPJa/Xnkg fXhHFZtCSfQvGblLZ2eMvaeECJH5GCxfx+qos+nN8igb9vMS/TRyYALcxydDAac1 SJdGjPqwZ05D/D8SEMvHUGWGmiW1JVKqVhxxnolk+q6L8djFVt9Q7HGxXKsjQFRo ycWFiKOLf8L1aR317HJvFfDHturbFXtf/p/c5mnVXQ568xdrPifgXznpXoh0uSOX 76/HtfThdVB910c6IWPigtFae0/7c9KqqOTdXwqzo2m67+fzXHGQ/HO2TLY5lpK1 EaHA7h6aivkdyFBUWNgeT90PGjxPxuDNTuIIws3Ji7VyorRKkRf56fA2IcloDfM0 XQK12U9Q5bee4oyhY2T3+Kpn2NChrMaY0p+Ddf0UQiw1wR8wR6vuWdWjJWauTFZ8 ALHpP0Im2tANobht7zYCobpuFphQCY2o6Fg4CUYYXAUFAimcqEmlYfAwlCk2Kb1n NpF3UN9c/mV1oIbakZ6KsQAaEGbCF0UBhuvHZsD8xv70Qg2K6zldLxis7vx/iir3 zvffJx27GEyYtcPvruD1+20qZCdAWY7CqeS3EaWnUdBmyc2wqvhNbeBgU476TBtI GOeXHG//3/QLKSswfK/A =QpMQ -----END PGP SIGNATURE----- --Sig_/AWzFb27idBRUbcsfO0haN3L--