From: Florian Schmaus <flow@gentoo.org>
To: Arthur Zamarin <arthurzam@gentoo.org>, gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH v4] greadme.eclass: new eclass
Date: Tue, 18 Jun 2024 22:48:48 +0200 [thread overview]
Message-ID: <621b8421-1ac7-45b3-8992-a22b51007b7c@gentoo.org> (raw)
In-Reply-To: <daf517d3-0b3a-4bf5-857c-033d1d2c74b2@gentoo.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 1950 bytes --]
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
[-- 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 --]
next prev parent reply other threads:[~2024-06-18 20:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-16 15:51 [gentoo-dev] [PATCH v4] greadme.eclass: new eclass Florian Schmaus
2024-06-16 18:15 ` Arthur Zamarin
2024-06-17 0:51 ` [gentoo-dev] " Duncan
2024-06-18 11:33 ` [gentoo-dev] " Florian Schmaus
2024-06-18 14:02 ` Ulrich Mueller
2024-06-18 14:53 ` Florian Schmaus
2024-06-18 18:21 ` Arthur Zamarin
2024-06-18 18:55 ` Ionen Wolkens
2024-06-18 20:48 ` Florian Schmaus [this message]
2024-06-19 8:32 ` Ulrich Mueller
2024-06-19 12:18 ` Florian Schmaus
2024-06-16 20:09 ` Ulrich Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=621b8421-1ac7-45b3-8992-a22b51007b7c@gentoo.org \
--to=flow@gentoo.org \
--cc=arthurzam@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox