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 A52791381F3 for ; Thu, 4 Jul 2013 07:44:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C1786E0A00; Thu, 4 Jul 2013 07:44:39 +0000 (UTC) Received: from juliette.telenet-ops.be (juliette.telenet-ops.be [195.130.137.74]) by pigeon.gentoo.org (Postfix) with ESMTP id 85A93E09FC for ; Thu, 4 Jul 2013 07:44:38 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by juliette.telenet-ops.be with bizsmtp id w7kd1l00s2khLEN067kdRQ; Thu, 04 Jul 2013 09:44:37 +0200 Date: Thu, 4 Jul 2013 09:41:28 +0200 From: Tom Wijsman To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration. Message-ID: <20130704094128.5e2e2f74@TOMWIJ-GENTOO> In-Reply-To: <20130704020019.GA13446@waltdnes.org> References: <20130701164149.131490f8@TOMWIJ-GENTOO> <20130701181749.GA3831@kroah.com> <20130701205615.18fdcea2@TOMWIJ-GENTOO> <20130701212542.60f86307@TOMWIJ-GENTOO> <20130701193330.GA31073@kroah.com> <20130701215045.5f8099d3@TOMWIJ-GENTOO> <20130703104555.GA9789@rathaus.eclipse.co.uk> <20130703144256.68e4aef8@TOMWIJ-GENTOO> <20130704020019.GA13446@waltdnes.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.19; 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-SHA1; boundary="Sig_/=r=dKH+F2p0c1FoWx/m_q.D"; protocol="application/pgp-signature" X-Archives-Salt: 3609b1c4-62d4-436b-9549-d9cbb8d0fb1f X-Archives-Hash: d524faf9897a8c64f015c251d52ae685 --Sig_/=r=dKH+F2p0c1FoWx/m_q.D Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 3 Jul 2013 22:00:19 -0400 "Walter Dnes" wrote: > Here's my user, not-a-developer, perspective. I think that there > should be a mechanism to enable one patch at a time. Here's the > rationale... Haven't tried this myself but I believe UNIPATCH_EXCLUDE using the /etc/portage/package.env mechanism should accomplish this. > Assume that there are 50 different patches available. I may > want/need features provided by 1 of those patches. I probably do > *NOT* want to enable the other 49 patches. This is similar in > concept to enabling one ~amd64 ebuild, versus globally enabling > ~amd64. We don't plan to add this amount of patches, we wouldn't be able to maintain that number of patches; just the active / most common / ... > Even if I can come up with the list of the 49 patches to exclude, > what happens when the next developer comes along with patch #51? > Does it get applied next time I build a kernel (ouch)? Yes, but why would this bother you? None of its code will be included in the build unless you explicitly enable it in the menu config. > IANAD (I Am Not A Developer), but if I did want to apply custom > patches, I think the right approach would be to somewhere manually > modify UNIPATCH_LIST. If that approach won't work, maybe a USE_EXPAND > flag make.conf might be the way to go. E.g. CUSTOM_PATCH=3D"foo bar" > would resolve to USE=3D"custom_patch_foo custom_patch_bar" Not sure how you would use UNIPATCH_LIST, can you give an example? As for USE_EXPAND, we want to avoid that; it adds an extra layer of configuration for the user as well as maintenance for the maintainer for no good reason, this whole idea works because patches are made optional and only affect the build if you enable them in the menu config. Applying the experimental genpatches tarball through the experimental USE flag is opt-in, enabling CONFIG_GENTOO_EXPERIMENTAL is opt-in and applying individual options in the menu config is opt-in. I don't see a reason to make individual patches opt-in; if the user experience problems with one of them, UNIPATCH_EXCLUDE should suffice. We can document the existence of this mechanism by documenting about it in the experimental USE flag. --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/=r=dKH+F2p0c1FoWx/m_q.D Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJR1ScsAAoJEJWyH81tNOV908MH/058xrj1w28gWb9a2WpSkURy 73P3Y9DJj57Q1drf/cxPlzN9A6fWbnLF5ais1O3NvAGQgs59gyYTvh6KFLzEZp0x w++erZLXmy64fQ1SlpRpW27GR2EElHYXXFeYQ6WNag9kDo08PA/meAST8XkrlD7K cDcrWm3tJEWNvM9EyuK/qWpjOGMuECQg+i0+lyygtOkJqzhvAgpEXNxHUIogxjj5 yrYGrA7/B0tqW3Nxx7RU7yXrLvDyPpi+NrUPthEfi6GR4638fK6gVgRyEsbHEB0J X6jJ6Tj8wwFjZif8dVSq9eFPe9DPtOflevDRCuiXPtGZwYEnHqkSUcgEZdDPIeY= =f2uZ -----END PGP SIGNATURE----- --Sig_/=r=dKH+F2p0c1FoWx/m_q.D--