1 |
Tom Wijsman wrote: |
2 |
> Steven J. Long wrote: |
3 |
> > Tom Wijsman wrote: |
4 |
> > > "Steven J. Long" wrote: |
5 |
> > > > If it does [affect the build by default] then it should never be |
6 |
> > > > applied, unless the user specifically asks for it, imo, and the |
7 |
> > > > resultant kernel is labelled -exp as you suggest. |
8 |
> > > |
9 |
> > > Yes, we are going to introduce an experimental USE flag for this. |
10 |
> > |
11 |
> > That's for the over-arching set of patches isn't it? Which takes care |
12 |
> > of the labelling. |
13 |
> |
14 |
> Yes, we currently have "base" and "extras" tarballs for genpatches; it |
15 |
> is trivial to add a "experimental" tarball to this set, all the |
16 |
> optional experimental patches will be in that tarball. This is also |
17 |
> handy for maintainers of other distros whom use genpatches. |
18 |
|
19 |
That's cool. The bit about the user explicitly opting-in to 'fragile' |
20 |
patches still is of concern, however. |
21 |
|
22 |
> > I think a lot of these things are checks that should happen before |
23 |
> > patches are included, and on every upgrade. So we need to separate |
24 |
> > out what the developer/ebuild-maintainer has to do to prepare files/, |
25 |
> > and what needs to happen in the ebuild itself. |
26 |
> |
27 |
> Please note that this discussion is regarding genpatches; so, there is |
28 |
> no files/ directory and the ebuild change is very minimal, changing one |
29 |
> or two numbers to indicate the genpatches version to use. |
30 |
> |
31 |
> Every time I add a patch to genpatches I compile a test kernel using a |
32 |
> test ebuild; I plan to add these checks to our genpatches scripts, then |
33 |
> I can call the checks script from the ebuild in a QA way. |
34 |
|
35 |
Ah OK, sorry for confusion in that case. Glad to hear you have QA covered. |
36 |
|
37 |
> > > > Unless of course the user specifically requests it. This can be a |
38 |
> > > > simple variable with a list of required patches, or whatever. |
39 |
> > > |
40 |
> > > With USE=-experimental (which will be the default) they are |
41 |
> > > excluded by default, after enabling that the user can exclude |
42 |
> > > patches by setting UNIPATCH_EXCLUDE through the package.env |
43 |
> > > mechanism. |
44 |
> > |
45 |
> > I'd feel happier if certain patches, the troublesome ones discussed, |
46 |
> > had to be explicity enabled, before the configuration options and the |
47 |
> > patch to kernel files took place. Perhaps via UNIPATCH_INCLUDE or |
48 |
> > USE=aufs. |
49 |
> |
50 |
> There shouldn't be a problem here unless the user applies a lot of |
51 |
> patches that could introduce a colliding patch; in this case the user |
52 |
> either has to fix the conflicting patch or exclude ours. We can't know |
53 |
> for ourselves which patches will be troublesome in this light; but |
54 |
> well, I feel like this only happens on a very exceptional basis. If an |
55 |
> user keeps this amount of patches, ours are probably not needed. |
56 |
|
57 |
No, the problem is as mentioned, with patches for which disabling the |
58 |
configure option, does not stop the patch from changing anything. Such |
59 |
as aufs, as has been outlined by Greg K-H earlier in the thread. |
60 |
|
61 |
This addresses the entirely reasonable concerns of users like Walter and |
62 |
myself, as well as the warning alarms sounded by an upstream maintainer and |
63 |
others. Not to address the issue risks derailing the whole effort before |
64 |
it has begun; and can hardly be called "Proper integration", imo. |
65 |
|
66 |
After all, these are experimental patches. If they don't play nicely, don't |
67 |
let them out of the sandbox, unless the user tells us to. |
68 |
|
69 |
Having a clear "policy" on that makes negotiating with patch authors much |
70 |
simpler too, and it's far more likely they'll fall into line where possible, |
71 |
just as upstreams are usually quite happy to apply portability patches: it |
72 |
means they get more users and feedback. |
73 |
|
74 |
Regards, |
75 |
steveL |
76 |
-- |
77 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |