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
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
