[GLEP44] was not entirely clear on the usage of filetype specifiers.
This document serves to provide some of the internal logic used by
Portage at the point of writing, as well as adding new types to cover
the rest of the tree, for the purposes of tree-signing coverage.

For any given directory with a Manifest file, every file located in that
directory, or a sub-directory must be listed in that Manifest file,
unless stated otherwise in the following sections. The Manifest file
must not contain an entry for itself.

When generating or validating a Manifest, or commiting to a version
control system, the package manager should endeavour to ignore files
created by a version control system, backup files from text editors. A
non-exhaustive list is suggested here: CVS/, .svn/, .bzr/, .git/, .hg/,
.#*, *.rej, *.orig, *.bak, *~.

During validation, this serves as an indicator that the package
manager may need to check subtree Manifest file.

A missing MANIFEST file may be treated as a minor (eg excluding an
entire category) or critical validation failure.

The failure should be considered as critical only if files that would
be directly covered by this Manifest are missing. Deletion of a
category-level Manifest while preserving the packages is forbidden.
Deletion of an entire category is not.

If repeated use of a common path prefix is considered a bloat problem, a
Manifest file should be added inside the common directory, however this
should not be done blindly, as bloat by inodes is more significant for
the majority of use cases.

The logic behind 5, 6, 7 is ensuring that every item that by it's
presence or absense may be dangerous should always be treated strictly.
(Consider epatch given a directory of patches ${FILESDIR}/${PV}/, where
it blindly includes them, or alternatively, the package.mask file or a
profile being altered/missing).

Note: The AUX entries should only be generated if we are generating a
compatible Manifest that supports older versions of Portage. They should
be generated along with the new type.

For generation of existing package Manifests, the AUX entries must
continue to be present for the standard Portage deprecation cycle.
The new entries may be included already in all Manifest files, as they
will be ignored by older Portage versions. Over time, ECLASS, DATA,
EXEC, UNKNOWN may replace the existing AUX type.

The adoption of this proposal does also affect [GLEPxx+1] as part of
this GLEP series, however this GLEP was an offset of the research in
that GLEP.