From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id BA7C415817D for ; Tue, 18 Jun 2024 18:55:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 965EAE2A3A; Tue, 18 Jun 2024 18:55:11 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3AC93E2A34 for ; Tue, 18 Jun 2024 18:55:11 +0000 (UTC) Date: Tue, 18 Jun 2024 14:55:07 -0400 From: Ionen Wolkens To: gentoo-dev@lists.gentoo.org Cc: Florian Schmaus , Ulrich Mueller Subject: Re: [gentoo-dev] [PATCH v4] greadme.eclass: new eclass Message-ID: Mail-Followup-To: gentoo-dev@lists.gentoo.org, Florian Schmaus , Ulrich Mueller References: <20240616155123.1016092-1-flow@gentoo.org> <45bcb8d5-bea7-49a2-81e8-ee2d161872bc@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3o6dc0QLrVf865u2" Content-Disposition: inline In-Reply-To: X-Archives-Salt: 868b018e-b990-42bf-908a-6d45824209d3 X-Archives-Hash: 427d3adc0dbc64f9b1e04902fef449c3 --3o6dc0QLrVf865u2 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=3D"..."`. > >> > >>> 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]. > >=20 > > Thanks for pointing this out. I think I understand now what arthur is > > asking for: > >=20 > > src_install() { > > =C2=A0=C2=A0=C2=A0 ... > > =C2=A0=C2=A0=C2=A0 local DOC_CONTENTS=3D"My README.Gentoo contents" > > =C2=A0=C2=A0=C2=A0 readme.gentoo_create_doc > > } > >=20 > > @arthur: is that right? >=20 > yes, exactly. Please, I suggest going over the existing eclass, you > might get surprised how much is supported already. >=20 > > 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? > >=20 > > In any case, I wouldn't be opposed to implement something like this if > > somebody asks for it. >=20 > 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=3Dyes local DOC_CONTENTS=3D"\ 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 " ") =2E.." 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. >=20 > 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. >=20 > 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). >=20 > >=20 > >> BTW, I like readme.gentoo-r1's autoformatting, because the message may > >> contain variables (like paths containing EPREFIX) that can expand to > >> different lengths. > >=20 > > Happy to add it. > >=20 > > 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 ;)). > >=20 > >=20 > > - Flow >=20 > --=20 > Arthur Zamarin > arthurzam@gentoo.org > Gentoo Linux developer (Python, pkgcore stack, QA, Arch Teams, GURU) >=20 --=20 ionen --3o6dc0QLrVf865u2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmZx2AoACgkQskQGsLCs QzTHywf+M38QaeUTQMU1gcH7kHPrbNqyUiLCDq4GY5JRU1kiJnW8RSw416tzKwS4 gHgc5hUPmqNJYZmQOzypIv+xDu48F2Dc9XCki6dOkY9PskYB9gDThibrbiNdDbbl Vg1LI8tB8S39xMKfd5kjXxXJ5dzWaoTk5wzEsX72MvZFc5hrEx/c7b+o19wGclWV qfwTcMmDmh7uaS461scdsAvEZBxBUoaDkx06K2VQN/7bKWDzc0bpCcOkviZPr6jA XCV/wTZUuEJo0lZj1wiP4a8yULrzCkJRMkDkX3IFeoiMcJRRiOiOgA+UK4V6SYyr jmXJU1JuYMxA7mRlL2WwkPHQjYMdiw== =WyyO -----END PGP SIGNATURE----- --3o6dc0QLrVf865u2--