On 18/06/2024 20.21, Arthur Zamarin wrote:
> On 18/06/2024 17.53, Florian Schmaus wrote:
>> 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.

Given that I have been working on this for some time, I became very 
familiar with readme.gentoo-r1.eclass' implementation.


>> 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. […]

Oh, greadme.eclass definitely duplicates functionality of 
readme.gentoo-r1.eclass…


> What I'm trying to push you into, is understanding if you really need a
> new eclass.

Yes, we have been there. Please look at the discussion in the thread 
"Improve readme.gentoo-r1.eclass" from two weeks ago, where it was 
attempted to do it without a new eclass.

The outcome was that here is no sensible way to implement all of the 
suggested behavior, that is now provided by greadme.eclass, into 
readme.gentoo-r1.eclass.

For this reason it became a new eclass. And again, I have no desire to 
bikeshed if the new eclass' name is greadme.eclass or 
readme.gentoo-r2.eclass. However, I do have a preference towards 
greadme.eclass, for the reasons explained before.

- Flow