On 02/06/2024 18.28, 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?

The hash file's size is constant, unlike README.gentoo, which even could 
theoretically be bigger than 4 KiB.  And, as you indicated, some 
filesystems will even inline the 4-bytes into the inode.

But actually, I would rather simply exclude README.gentoo from 
decompression. This would make the eclass simpler. Many (most?) 
README.gentoo files are below 4 KiB uncompressed, hence the same 
argument could be made that compressing those files does not buy us much 
usable disk space.

However, you argued against using "docompress -x" in your mail from 
2024-10-01.

Frankly, I don't care much. But I am a little bit tired of reading the 
same elog output over and over again. Nearly daily I go through all elog 
messages on my machines, and a large fraction is just repetitive, mainly 
caused by readme.gentoo-r1.eclass (and others who should be using 
readme.gentoo-r1.eclass but do not).

I have a hard time not limiting myself to ewarn and higher messages. 
Quite likely other Gentoo users are in the same situation. 
Unfortunately, it seems likely that I would then miss valuable information.

Therefore we should take action. Which is either not showing 
GENTOO.readme upon updates *or* only showing it only if it changes when 
updating a package.

The latter is what this patchset tries to achieve.

- Flow