Tom Wijsman wrote: > Steven J. Long 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.
That's cool. The bit about the user explicitly opting-in to 'fragile' patches still is of concern, however. > > 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. Ah OK, sorry for confusion in that case. Glad to hear you have QA covered. > > > > 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. No, the problem is as mentioned, with patches for which disabling the configure option, does not stop the patch from changing anything. Such as aufs, as has been outlined by Greg K-H earlier in the thread. This addresses the entirely reasonable concerns of users like Walter and myself, as well as the warning alarms sounded by an upstream maintainer and others. Not to address the issue risks derailing the whole effort before it has begun; and can hardly be called "Proper integration", imo. After all, these are experimental patches. If they don't play nicely, don't let them out of the sandbox, unless the user tells us to. Having a clear "policy" on that makes negotiating with patch authors much simpler too, and it's far more likely they'll fall into line where possible, just as upstreams are usually quite happy to apply portability patches: it means they get more users and feedback. Regards, steveL -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
