On Tue, Jun 18, 2024 at 09:21:56PM +0300, Arthur Zamarin wrote:
> 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.

fwiw I do think heredoc is "nicer", e.g. I could indent (thanks to the
- in <<-EOF, and no need for \ to keep alignment) nvidia's kind of ugly:

	local DISABLE_AUTOFORMATTING=yes
	local DOC_CONTENTS="\
Trusted users should be in the 'video' group to use NVIDIA devices.
You can add yourself by using: gpasswd -a my-user video\
$(usev modules "
<dynamic content based on USE>")
..."

Not that I think it's by any means necessary, and fwiw if I really
wanted this, don't even need a new function and could do:

	local DOC_CONTENTS
	read -r -d '' DOC_CONTENTS <<-EOF
		line1
		line2
	EOF


Not that it isn't ugly too.

> 
> 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)
> 




-- 
ionen