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 E8B7F1381F3 for ; Thu, 4 Jul 2013 05:26:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E8D99E0964; Thu, 4 Jul 2013 05:26:17 +0000 (UTC) Received: from smtpout.karoo.kcom.com (smtpout.karoo.kcom.com [212.50.160.34]) by pigeon.gentoo.org (Postfix) with ESMTP id DA517E08C0 for ; Thu, 4 Jul 2013 05:26:16 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.87,992,1363132800"; d="scan'208";a="21615220" Received: from unknown (HELO rathaus.eclipse.co.uk) ([109.176.244.218]) by smtpout.karoo.kcom.com with ESMTP; 04 Jul 2013 06:25:58 +0100 Date: Thu, 4 Jul 2013 06:27:59 +0100 From: "Steven J. Long" To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration. Message-ID: <20130704052759.GB13271@rathaus.eclipse.co.uk> Mail-Followup-To: gentoo-dev@lists.gentoo.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> 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: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130703144256.68e4aef8@TOMWIJ-GENTOO> X-Archives-Salt: e9abb33c-8a9e-404e-8c4c-50e6f00b9fee X-Archives-Hash: 41ba8075a223bcabe178405b97d1074a Tom Wijsman wrote: > "Steven J. Long" wrote: > > If it does [affect the build by default] then it should never be > > applied, unless the user specifically asks for it, imo, and the > > resultant kernel is labelled -exp as you suggest. > > Yes, we are going to introduce an experimental USE flag for this. That's for the over-arching set of patches isn't it? Which takes care of the labelling. > > > It's just a matter of embedding each + block in the diff with a > > > config check and updating the counts. .. > > > I can convert the original developer's patch whenever he updates > > > it; or on top of that, write a script to generate the original > > > patch back. > > Please, just keep a copy of the original patch as well as the modified > > output from the script, somewhere reasonable to you, if you are doing > > any editing. Traceability is essential here. > > The need to keep duplicates around is a broken design; if you would > need to do this, there is something worse going on. There is indeed: there's major changes to other parts of the kernel tree, even when the patch's configuration options are set to off, as they are by default (or must be in the Gentoo experimental config patch.) That's the reason they were not accepted, as has been discussed earlier in the thread. > But yes, some git branches can easily cover the editing part. I think a lot of these things are checks that should happen before patches are included, and on every upgrade. So we need to separate out what the developer/ebuild-maintainer has to do to prepare files/, and what needs to happen in the ebuild itself. > > Personally I think it ill-advised, and would prefer simply that the > > patch were not applied if the above process in your testing prior to > > usage, showed that it would affect other parts of the build > > inappropriately, even when configured off. Or it's known to do so, > > like aufs. > > Maybe, we can hear whether the patch authors want to do something about > this, so we don't have to convert patches like this; maybe most of them > are willing to do this without a problem. The conversation is definitely worth having. Especially if Gentoo runs automated tests on the patchsets to verify previously "safe" patches are still safe to apply unconditionally, ie that all changes are #ifdef or #if guarded. > Though, there are going to be > parts that they want to unconditionally apply, which is why we will > need to wrap those parts with a check. Indeed; upstream patch authors are not going to suddenly change, especially with the known-troublesome cases, while there is still the need to make the patches available to users who would otherwise be applying them without Gentoo -exp labelling. > > Unless of course the user specifically requests it. This can be a > > simple variable with a list of required patches, or whatever. > > With USE=-experimental (which will be the default) they are excluded by > default, after enabling that the user can exclude patches by setting > UNIPATCH_EXCLUDE through the package.env mechanism. I'd feel happier if certain patches, the troublesome ones discussed, had to be explicity enabled, before the configuration options and the patch to kernel files took place. Perhaps via UNIPATCH_INCLUDE or USE=aufs. Regards, steveL. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)