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