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 E971015817D for ; Tue, 18 Jun 2024 18:22:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B9507E2A3F; Tue, 18 Jun 2024 18:22:07 +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 56E24E2A3B for ; Tue, 18 Jun 2024 18:22:07 +0000 (UTC) Message-ID: Date: Tue, 18 Jun 2024 21:21:56 +0300 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 User-Agent: Mozilla Thunderbird Subject: Re: [gentoo-dev] [PATCH v4] greadme.eclass: new eclass To: gentoo-dev@lists.gentoo.org, Florian Schmaus , Ulrich Mueller References: <20240616155123.1016092-1-flow@gentoo.org> <45bcb8d5-bea7-49a2-81e8-ee2d161872bc@gentoo.org> From: Arthur Zamarin Content-Language: en-US In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------mUFyw0YlTJuYfWvIsOrDJMfF" X-Archives-Salt: 7b507860-a7d5-417b-a0ba-c1a49c5dd419 X-Archives-Hash: 129b8eaebb1da0930e99fcae0e670d68 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------mUFyw0YlTJuYfWvIsOrDJMfF Content-Type: multipart/mixed; boundary="------------eKYI7IEjplxm1e3ToVafdf6U"; protected-headers="v1" From: Arthur Zamarin To: gentoo-dev@lists.gentoo.org, Florian Schmaus , Ulrich Mueller Message-ID: Subject: Re: [gentoo-dev] [PATCH v4] greadme.eclass: new eclass References: <20240616155123.1016092-1-flow@gentoo.org> <45bcb8d5-bea7-49a2-81e8-ee2d161872bc@gentoo.org> In-Reply-To: --------------eKYI7IEjplxm1e3ToVafdf6U Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 proces= s >>>>> 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 a= s >>>> 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 loca= l >>> 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? 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? >=20 > 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). >=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) woul= d > probably also be an option (and has a --uniform-spacing option ;)). >=20 >=20 > - Flow --=20 Arthur Zamarin arthurzam@gentoo.org Gentoo Linux developer (Python, pkgcore stack, QA, Arch Teams, GURU) --------------eKYI7IEjplxm1e3ToVafdf6U-- --------------mUFyw0YlTJuYfWvIsOrDJMfF Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE/axFlFuH2ptjtO5EAqCvUD0SBQQFAmZx0EQACgkQAqCvUD0S BQSYEAgAmRWzMwu+KVulRgymeb530wRYzvZQEDVJ5Lm7aU5gXyaO2mkQdm7BYwCX xspUlzinQvT0cR6/Fzze+aPvbi5JEIvPxzI/VDfgz9rnk5BpxZLj7RGXopP8pFXP hW64OLe9odWdRuIlbHdfyiMlQ9M+ZJ5onefliiFc45mLK/ECdNcOhW0eMMC++clr oNc0SfaUHbdDPsD2I1RvBbSy68cA21D75UKFokqviNgKCQK2nGI6VBvMxbpaw8im 8VZbqkIvzBg+SifttxNNtJmwMcTSKehdgEo83z7qV0VRhDgZqNmlarAfNvAQccj/ extJCWM1xSc3ufVEvqn4eRYPHKQNAQ== =oBJ0 -----END PGP SIGNATURE----- --------------mUFyw0YlTJuYfWvIsOrDJMfF--