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 6A26A158451 for ; Wed, 10 Jan 2024 15:10:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9A7E3E2AB5; Wed, 10 Jan 2024 15:10:44 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 5DE7EE2A9C for ; Wed, 10 Jan 2024 15:10:44 +0000 (UTC) From: Ulrich Mueller To: Florian Schmaus Cc: gentoo-dev@lists.gentoo.org, Sam James , pacho@gentoo.org Subject: Re: [gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass In-Reply-To: <93425f77-7995-4040-9b4f-243216dcf42b@gentoo.org> (Florian Schmaus's message of "Wed, 10 Jan 2024 15:30:28 +0100") References: <20240106170153.1581902-1-flow@gentoo.org> <87r0ipmos3.fsf@gentoo.org> <93425f77-7995-4040-9b4f-243216dcf42b@gentoo.org> Date: Wed, 10 Jan 2024 16:10:32 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) 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; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Archives-Salt: 32d0dd5d-91e4-4151-85bc-a06391aa3c5b X-Archives-Hash: aeff9bd8a051c73c216bae7bcd9802a5 --=-=-= Content-Type: text/plain >>>>> On Wed, 10 Jan 2024, Florian Schmaus wrote: > On 10/01/2024 14.58, Ulrich Mueller wrote: >> Looks like readme.gentoo-r1 already gives you control over this: >> # If you want to show them always, please set FORCE_PRINT_ELOG to a non empty >> # value in your ebuild before this function is called. >> # This can be useful when, for example, DOC_CONTENTS is modified, then, you can >> # rely on specific REPLACING_VERSIONS handling in your ebuild to print messages >> # when people update from versions still providing old message. > It is easy to forget setting FORCE_PRINT_ELOG, just as it is easy to > forget to unset it again. > An automatism is always preferable over a manual solution. Maybe I want manual control? For example, when I fix a typo in the README file then I don't want to show it to users again. >>> Just to clarify: you are agreeing that excluding the readme doc from >>> being compressed is fine? >> Please respect the user's compression settings there. IMHO >> overriding >> them with docompress -x is a big no-no. > Then why does "docompress -x" exist at all? Short answer, because some upstream programs access these directories and cannot cope with compressed files there. Long answer, see the previous discussion on this list [1] and in bug 250077 [2]. > There seems to be a big win-win if we override the compression > settingin this case. I tend to disagree. We shouldn't override users' choices unless absolutely necessary. Ulrich [1] https://archives.gentoo.org/gentoo-dev/message/2fd5f58132881ef69219c126a525bce3 [2] https://bugs.gentoo.org/250077 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmWes2gPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4urDUIAJ4vLi2Hs3CGRRoo3zVZaMZXWW0YVsMmPxk3 XLjoVFwk/ODdEydy6+sxV5Nnv8ayug53IHUjTjbAAG4OjNfbgxWv3GrHwOTp0X7D cdn0b7UFOLN69H18eRw2wQq4Av/XWwSQ15SWWSTQ/OebH3b84k1VgxJBUCRoyE33 yRWciMGgovsTj55xwbzN6QNg2BDLgl9dsthB0QnBHkrAOmHbZJqeLgoyewmW4sGD sM1EX+Du5rLDo4C9WFD4v/SuUxuMHU1DDV8ZeUgzDAHZXXvngBPhcOr6qLaFnRoN wi6ZCEjsszvzqQG0ao6s0VX0DTXvTHhGC29a/v/D3bFxZAz5ZmI= =YJTY -----END PGP SIGNATURE----- --=-=-=--