1 |
>>>>> On Tue, 20 Sep 2016, Kent Fredric wrote: |
2 |
|
3 |
> So a reduced suggestion would be: |
4 |
|
5 |
> 1. Add a PATCHES var to EAPI7 |
6 |
> 2. PATCHES is analogous to SRC_URI, a string |
7 |
> 3. PATCHES supports USE conditionals |
8 |
|
9 |
I am not convinced that USE-conditional patching should be encouraged. |
10 |
Because so far the policy was that whenever possible, patches should |
11 |
be applied unconditionally and any conditionals should be configure |
12 |
options. So that patches could eventually be sent upstream. |
13 |
|
14 |
It is somewhat similar to epatch's arch conditional patching (as in |
15 |
10_sparc_foo.patch) which for the same reason was labelled as "highly |
16 |
discouraged" in 2010. Also that feature wasn't added to eapply. |
17 |
|
18 |
> 4. PATCHES is ordered. |
19 |
> 5. ${FILESDIR} works as it always did |
20 |
> 6. PATCHES describes components of FILESDIR |
21 |
> 7. PATCHES is evaluated in terms of USE to yield EFFECTIVE_PATCHES, an array |
22 |
> 8. Default src_prepare applied eapply to all values in EFFECTIVE_PATCHES |
23 |
> 9. Items in PATCHES are checked by repoman "they must exist" |
24 |
|
25 |
Under that new scheme, how would I apply patches unpacked into |
26 |
WORKDIR? In EAPI 6, I can put them into the PATCHES variable and use |
27 |
the default src_prepare to process it. |
28 |
|
29 |
> The difference between this suggestion and the previous one importantly |
30 |
> is it can't be used to whitelist, it can only be used to |
31 |
|
32 |
> 1. Simplify how patches are applied for people who want it |
33 |
> 2. Add extra assurance to repoman if people use the feature |
34 |
|
35 |
> Neither of these are exactly "Compelling" features, but it would |
36 |
> in part reduce the work. It would also avoid double-bookkeeping |
37 |
> by adding no features that require double-bookkeeping, and would simply be a |
38 |
> generalization/enhancement of similar features already found in ebuilds. |
39 |
|
40 |
Ulrich |