>>>>> On Tue, 18 Jun 2024, Florian Schmaus wrote:

>>> Finally, unlike readme.gentoo-r1.elcass, this eclass does not need
>>> to store the content of the readme in an environment variable. Not
>>> having to store the content in an environment variable reduces the
>>> pollution of the environment (sadly, this only refers to the process
>>> environment).

>> I'll be honest, I never felt this is really needed? From looking at
>> the current -r1 eclass, you could define DOC_CONTENTS just before
>> invoking readme.gentoo_create_doc, so you could for example modify as
>> you want the message and use `local DOC_CONTENTS="..."`.

> readme.gentoo-r1.eclass requires DOC_CONTENTS to be part of the
> package's environment to show it later in readme.gentoo_print_elog(),
> which is typically invoked in pkg_postinst(). If DOC_CONTENTS is local
> to readme.gentoo_create_doc(), then it wont be able in pkg_postinst()
> and can potentially not be obtained from the README.gentoo file
> because that file may be compressed.

> For greadme.eclass, the file is no longer compressed, therefore
> greadme.eclass does not need to carry a variable in the package's
> environment.

These are two different variables that must not be confused.
readme.gentoo-r1 has DOC_CONTENTS as an "input variable" that is
assigned by the ebuild. It creates the actual file from it (possibly
doing some automatic formatting).

The contents of the final file is then saved in another variable
README_GENTOO_DOC_VALUE, which is used in readme.gentoo_print_elog to
output the message.

BTW, I like readme.gentoo-r1's autoformatting, because the message may
contain variables (like paths containing EPREFIX) that can expand to
different lengths.

Ulrich