On 18/06/2024 17.53, Florian Schmaus wrote:
> On 18/06/2024 16.02, Ulrich Mueller wrote:
>>>>>>> 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
>>[DOC_CONTENTS vs README_GENTOO_DOC_VALUE].
> 
> Thanks for pointing this out. I think I understand now what arthur is
> asking for:
> 
> src_install() {
>     ...
>     local DOC_CONTENTS="My README.Gentoo contents"
>     readme.gentoo_create_doc
> }
> 
> @arthur: is that right?

yes, exactly. Please, I suggest going over the existing eclass, you
might get surprised how much is supported already.

> If so, then we could always add such an API to greadme.eclass too.
> However, it appears that it simply would duplicate what can already be
> done via greadme_stdin. Is there a compelling reason for such an API
> that I am missing?
> 
> In any case, I wouldn't be opposed to implement something like this if
> somebody asks for it.

I think you are looking at it from the wrong side. Thinking in this
"impl" possible now, I think *you* are duplicating work stuff which was
supported in readme.gentoo-r1. I don't see anything supportted by
greadme_stdin and unsupported with this `local DOC_CONTENTS` stuff.

What I'm trying to push you into, is understanding if you really need a
new eclass. With all of those things, I believe greadme eclass is just a
duplicate.

I think if there is a small thing you want to have in -r1 eclass, it is
already supported or easily added. The support for a $FILESDIR is
something I see more rare than direct DOC_CONTENTS (in global as common,
and as local as a possible way).

> 
>> BTW, I like readme.gentoo-r1's autoformatting, because the message may
>> contain variables (like paths containing EPREFIX) that can expand to
>> different lengths.
> 
> Happy to add it.
> 
> Any preference regarding the auto-formatting tool? The
> readme.gentoo-r1.eclass uses fold, but fmt (both are in coreutils) would
> probably also be an option (and has a --uniform-spacing option ;)).
> 
> 
> - Flow

-- 
Arthur Zamarin
arthurzam@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, QA, Arch Teams, GURU)