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

[Ulrich Mueller]

>>>>> On Sat, 17 Sep 2016, Kent Fredric wrote:

> Just an idea that seemed obvious enough and obviously missing.

> 1. Have, in a future EAPI, a variable (I'm going to call it "FILES" as
> a stand-in for now ).

> 2. FILES contains an array (or perhaps whitespace delimited string) of
> entries (or perhaps expressions) relative to
> ${repository_location}/${CATEGORY}/${PN}/files/

> 3. Each entry in FILES dictates that the given file is "Used by" the
> ebuild.

Do you mean "file" in its Unix meaning here, i.e. including
directories? Or only regular files?

> 4. the FILES variable is expanded and interpreted during package
> sourcing

> 5. "repoman full" and "repoman ci" must ensure any entry listed in FILES
> exists

> 6. "repoman full" and "repoman ci" must ensure any use of ${FILESDIR}
> without a declared FILES variable is a failure.

> 7. Under this future EAPI, the location of where ${FILESDIR} expands to
> changes to a location within
> ${PORTAGE_TEMPDIR}/portage/${CATEGORY}/${PF}/files

> 8. The contents of ${PORTAGE_TEMPDIR}/portage/${CATEGORY}/${PF}/files
> is generated from the source-time $FILES entry by mapping entries from
> ${repostory_location}, either by symlink or by copy (though copy is
> preferred to avoid potential side effects), mapping their heirachy
> exactly ( that is, preserving directory structure )

> 9. Files not listed in/indicated by $FILES are thus unavailable to the
> ebuild at runtime and will not be seen in ${FILESDIR}, even if they are
> in ${repository_location}

AFAICS that proposal goes into a direction which is somewhat opposite
to what we have pursued in EAPI 6. There, we have allowed directories
as arguments to eapply, in order to simplify application of patchsets.
Now maintainers would have to list all single files contained in the
directory again.

Also I am not sure if I like the additional burden imposed on ebuild
maintainers by requiring double bookkeeping. FILESDIR is already a
well defined location for the support files needed by a package.

> :: Benefits ::

> [...]

> 4. Due to referential integrity, it should be trivial to identify which
> files are needed by a given ebuild, and which files are now redundant,
> assisting with keeping the tree pruned.

How does a file in FILESDIR get stale? The typical scenario is that a
patch will no longer be needed after a version bump and pruning of old
ebuild versions. I fear that with FILES the problem would simply be
shifted: instead of forgetting to delete the stale file, people would
forget removing the patch from the FILES list.

Ulrich