From: Arthur Zamarin <arthurzam@gentoo.org>
To: gentoo-dev@lists.gentoo.org, Florian Schmaus <flow@gentoo.org>,
Ulrich Mueller <ulm@gentoo.org>
Subject: Re: [gentoo-dev] [PATCH v4] greadme.eclass: new eclass
Date: Tue, 18 Jun 2024 21:21:56 +0300 [thread overview]
Message-ID: <daf517d3-0b3a-4bf5-857c-033d1d2c74b2@gentoo.org> (raw)
In-Reply-To: <a9578c91-73b9-431c-b11c-09c272fe68e8@gentoo.org>
[-- Attachment #1.1: Type: text/plain, Size: 3397 bytes --]
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)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2024-06-18 18:22 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 [this message]
2024-06-18 18:55 ` Ionen Wolkens
2024-06-18 20:48 ` Florian Schmaus
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=daf517d3-0b3a-4bf5-857c-033d1d2c74b2@gentoo.org \
--to=arthurzam@gentoo.org \
--cc=flow@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=ulm@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