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 958B115817D for ; Sun, 2 Jun 2024 18:24:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 50A50E2BD0; Sun, 2 Jun 2024 18:24:28 +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)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id ED0E7E2BC4 for ; Sun, 2 Jun 2024 18:24:27 +0000 (UTC) From: Ulrich Mueller To: Eli Schwartz Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH 1/4] readme.gentoo-r1.eclass: display readme if content changed (or fresh install) In-Reply-To: (Eli Schwartz's message of "Sun, 2 Jun 2024 13:51:41 -0400") References: <20240109083914.242561-1-flow@gentoo.org> <20240602135716.66992-1-flow@gentoo.org> <20240602135716.66992-2-flow@gentoo.org> Date: Sun, 02 Jun 2024 20:24:21 +0200 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: 630eaeeb-7252-4bc6-b70a-4e256f2d827f X-Archives-Hash: ca0b11404051e9b14ef7d1724180ba43 --=-=-= Content-Type: text/plain >>>>> On Sun, 02 Jun 2024, Eli Schwartz wrote: > readme.gentoo-r1.eclass as proposed in this thread is exactly such an > upstream program (gentoo is the upstream, and gentoo cannot cope with > compressed files there). > It strikes me as rules lawyering to use this as an argument against > the eclass, but whatever. The alternative to `docompress -x` is to > *not have to decompress* when comparing the compressed contents of two > files, which means recording persistent state. > There is one approach that I can think of for this: > - recording state in a second file (additional to README.gentoo itself) > If you dislike this solution, and are unwilling to back down on > "docompress -x", then my personal feeling is that it is *your* > responsibility to come up with an alternative mechanism for > implementing the functionality. Installing another file just for the sake of avoiding "docompress -x" doesn't solve the problem but makes it worse, IMHO. Rather don't compress README.gentoo then. (Also, I still don't understand the argument about different compress programs. That's not likely to happen very often. You could go for best effort there, and if it fails, consider the files as different. There's no need for exact science when the only thing that can happen is additional output.) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmZcuNUPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4ugH0IAJqIfD7cyxlZbmpvT1gFWtDKdl4j3/NNqMgc lnYuBlRyESnSNcyOwr01YtVZbdrVeDSnZBp+OmGv5MJpVezUpNhgdNZh4lCTjdwG 63REjR2GbE/UeNZ1kFklR0boRjR8o4bwRzTOQ361kGqcms3fv1ndeS+bP/U27uuE 2KZhach8jFVvCZf7fDVCLtbGToacucQLe+rjDm6Br3FPTnJfYDFDfTUQmCXlUeUB KcKgTOdQcBZDqJTNhgWFLUxFpEGhq2AiHwy4ObLL3ml+r3g0zLlf0hfxt1lo2ZOv z9QEXpiq5NnlwgqYDvJgLHASV9DUYg7QPsQ2XeYhUwnGr7bGCZQ= =36nt -----END PGP SIGNATURE----- --=-=-=--