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