public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ulrich Mueller <ulm@gentoo.org>
To: Eli Schwartz <eschwartz93@gmail.com>
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)
Date: Sun, 02 Jun 2024 20:24:21 +0200	[thread overview]
Message-ID: <umso3b3u2@gentoo.org> (raw)
In-Reply-To: <ae68c798-5c45-433d-8b9e-e39e619f2e85@gmail.com> (Eli Schwartz's message of "Sun, 2 Jun 2024 13:51:41 -0400")

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

>>>>> 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.)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

  reply	other threads:[~2024-06-02 18:24 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-06 17:01 [gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass Florian Schmaus
2024-01-06 17:01 ` [gentoo-dev] [PATCH 1/1] greadme.eclass: new eclass Florian Schmaus
2024-01-06 17:21 ` [gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass Michał Górny
2024-01-09  8:30   ` Florian Schmaus
2024-01-09  8:39     ` [gentoo-dev] [PATCH v2 1/3] greadme.eclass: new eclass Florian Schmaus
2024-01-09  8:39       ` [gentoo-dev] [PATCH v2 2/3] add UNPACKER_NO_BANNER variable Florian Schmaus
2024-01-09  8:45         ` [gentoo-dev] " Florian Schmaus
2024-01-09  8:39       ` [gentoo-dev] [PATCH v2 3/3] greadme.eclass: set UNPACKER_NO_BANNER Florian Schmaus
2024-01-09 11:23       ` [gentoo-dev] [PATCH v2 1/3] greadme.eclass: new eclass David Seifert
2024-01-09 11:30         ` Florian Schmaus
2024-06-02 13:57       ` [gentoo-dev] [PATCH 0/4] Improve readme.gentoo-r1.eclass Florian Schmaus
2024-06-02 13:57         ` [gentoo-dev] [PATCH 1/4] readme.gentoo-r1.eclass: display readme if content changed (or fresh install) Florian Schmaus
2024-06-02 15:34           ` Ulrich Mueller
2024-06-02 15:48             ` Eli Schwartz
2024-06-02 16:28               ` Ulrich Mueller
2024-06-02 17:48                 ` Florian Schmaus
2024-06-02 17:51                 ` Eli Schwartz
2024-06-02 18:24                   ` Ulrich Mueller [this message]
2024-06-04 15:15                     ` Florian Schmaus
2024-06-04 17:45                       ` Ulrich Mueller
2024-06-04 18:28                         ` Florian Schmaus
2024-06-04 18:33                           ` Eli Schwartz
2024-06-04 18:40                           ` Ulrich Mueller
2024-06-04 18:37                         ` Ionen Wolkens
2024-06-04 18:59                           ` Ionen Wolkens
2024-06-02 16:16             ` Florian Schmaus
2024-06-02 13:57         ` [gentoo-dev] [PATCH 2/4] readme.gentoo-r1.eclass: use _GREADME_TMP_FILE in existing code Florian Schmaus
2024-06-02 13:57         ` [gentoo-dev] [PATCH 3/4] readme.gentoo-r1.eclass: add readme.gentoo_stdin() Florian Schmaus
2024-06-02 13:57         ` [gentoo-dev] [PATCH 4/4] readme.gentoo-r1.eclass: add readme.gentoo_file() Florian Schmaus
2024-06-02 15:25         ` [gentoo-dev] [PATCH 0/4] Improve readme.gentoo-r1.eclass Ulrich Mueller
2024-06-02 16:12           ` Florian Schmaus
2024-06-02 16:40             ` Ulrich Mueller
2024-06-02 17:34               ` Florian Schmaus
2024-01-09  9:59     ` [gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass Michał Górny
2024-01-09 10:39       ` Florian Schmaus
2024-01-09 10:43         ` Michał Górny
2024-01-09 10:47           ` Florian Schmaus
2024-01-10 11:04 ` Sam James
2024-01-10 13:23   ` Florian Schmaus
2024-01-10 13:58     ` Ulrich Mueller
2024-01-10 14:30       ` Florian Schmaus
2024-01-10 15:10         ` Ulrich Mueller
2024-01-10 15:54           ` Florian Schmaus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=umso3b3u2@gentoo.org \
    --to=ulm@gentoo.org \
    --cc=eschwartz93@gmail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox