On Thu, 4 Jul 2013 06:27:59 +0100 "Steven J. Long" <sl...@rathaus.eclipse.co.uk> wrote:
> 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. Yes, we currently have "base" and "extras" tarballs for genpatches; it is trivial to add a "experimental" tarball to this set, all the optional experimental patches will be in that tarball. This is also handy for maintainers of other distros whom use genpatches. > > > > 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. > > > > 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. Please note that this discussion is regarding genpatches; so, there is no files/ directory and the ebuild change is very minimal, changing one or two numbers to indicate the genpatches version to use. Every time I add a patch to genpatches I compile a test kernel using a test ebuild; I plan to add these checks to our genpatches scripts, then I can call the checks script from the ebuild in a QA way. > > > 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. There shouldn't be a problem here unless the user applies a lot of patches that could introduce a colliding patch; in this case the user either has to fix the conflicting patch or exclude ours. We can't know for ourselves which patches will be troublesome in this light; but well, I feel like this only happens on a very exceptional basis. If an user keeps this amount of patches, ours are probably not needed. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
