Re: [gentoo-dev] [PATCH v4] greadme.eclass: new eclass

[Florian Schmaus <flow@gentoo.org>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2341 bytes --]

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?

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.


> 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

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 17797 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]