On 6/2/24 12:28 PM, Ulrich Mueller wrote:
>>>>>> On Sun, 02 Jun 2024, Eli Schwartz wrote:
> 
>> Per the commit message, the old readme and the new readme can have the
>> same contents, but be compressed by different compressors on the live
>> system vs the image, and/or a compressor with unstable algorithms,
>> and/or one that isn't installed at the time of merging.
> 
>> Given you've explicitly rejected disabling compression, I don't quite
>> see how you can have your cake and eat it too.
> 
> How is installing another file (4 KiB on many file systems) an
> improvement over disabling compression for README.gentoo itself?


I didn't say it was.

The improvement is to disable compression for README.gentoo itself.
*You* are the one insisting on another approach.


Remember the original argument against disabling compression:

"""
> Then why does "docompress -x" exist at all?

Short answer, because some upstream programs access these directories
and cannot cope with compressed files there.
"""

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.


-- 
Eli Schwartz