Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist

[Kent Fredric]

On Tue, 20 Sep 2016 09:02:41 +0200
Michał Górny <mgorny@g.o> wrote:

> Finally, the same though occurred to me as to ulm. People will forget
> to update the variable. They will forget to update it when adding,
> and they will waste their time on build that is going to fail somewhere
> at doinit in the end -- how nice is that? Then, they will forget to
> update it when removing and the file will be kept stale.
>
> Any solution you can try to invent to solve those problems, or make
> the system any more friendly, is actually making it more complex,
> harder to comprehend and even more costly.

Yeah, I'd probably have to scrap most of my suggestions and restrict the design
to something that was only an "optional extra" in order to be useful.

If I was to re-do the concept, it would be mostly a hashover of what we use in Perl
for patches.

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
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"

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.

Anything that needed something more fancy than PATCHES would sill be able
to and do its own stuff, and it would simply not get any benefits of repoman
side consistency checks.

And people who needed extra magic could also do:


src_prepare() { 
    # extra stuff
    default; # does eapply EFFECTIVE_PATCHES && eapply_user
}