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 2D0A415817D for ; Thu, 13 Jun 2024 12:53:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3E73EE2ACC; Thu, 13 Jun 2024 12:53:39 +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 DB82EE2AAC for ; Thu, 13 Jun 2024 12:53:38 +0000 (UTC) Message-ID: <914fbd78-11b9-462c-86f4-9b89bb566166@gentoo.org> Date: Thu, 13 Jun 2024 14:53:31 +0200 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 v3 0/1] greadme.eclass: new eclass To: gentoo-dev@lists.gentoo.org, Ionen Wolkens References: <20240613083928.165509-1-flow@gentoo.org> Content-Language: en-US, de-DE From: Florian Schmaus In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 1bd40c1c-9c54-429d-849c-37064b5af2cd X-Archives-Hash: 6fa30b1d4ecc7115f27fb94852f3cbd8 On 13/06/2024 13.59, Ionen Wolkens wrote: > On Thu, Jun 13, 2024 at 10:39:24AM +0200, Florian Schmaus wrote: >> Following up on the discussion of the last patchset, this >> - moves the functionally into a new eclass, as adjusting the existing >> eclass to export new phase functions is not viable. >> - excludes the README.gentoo from decompression, as all other >> presented approaches add complexity and cause additional disk space >> consumption. While on the other hand, README.gentoo files are >> typically very small because they should be suitable as pkg_postinst >> output, so ther is often not much gained by compressing them. >> - adds a GREADME_SHOW show option, to manually override the behavior >> (as requested by ionen). > > I don't recall requesting anything, or was it something i said on > IRC that I forgot about? No, that seems to be a misunderstanding then. You wrote about the maintainer being able to choose when the readme is worth showing again and that a comparison would also "display it for minor style or typo fixes.". I thought that this was asking for a manual override. I am sorry, seems that I got that wrong. > Also I assume GREADME_SHOW is actually GREADME_FORCE? It's actually the other way around. Latest HEAD of greadme.eclass has # @ECLASS_VARIABLE: GREADME_SHOW # @DEFAULT_UNSET # @DESCRIPTION: # If set to "yes" then unconditionally show the contents of the readme # file in pkg_postinst via elog. If set to "no", then do not show the # contents of the readme file, even if they have changed. - Flow