Re: [gentoo-dev] [PATCH 1/4] readme.gentoo-r1.eclass: display readme if content changed (or fresh install)

[Florian Schmaus <flow@gentoo.org>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2253 bytes --]

On 04/06/2024 19.45, Ulrich Mueller wrote:
>>>>>> On Tue, 04 Jun 2024, Florian Schmaus wrote:
> 
>> Both is fine with me.
> 
>> That said, many filesystem support inline data. If I am not mistaken,
>> then its even enabled by default for xfs (which we recommend in the
>> handbook) and btrfs. Also some README.gentoo files become suitable for
>> inlining after compression (btrfs' limit is 2048 bytes).
> 
> I see 48 README.gentoo* files on my system here, and the _uncompressed_
> size of the largest of them (belonging to www-client/firefox) is 1238
> bytes. So, by your metric all of them could be inlined even without
> compressing them. 14 of the 48 files aren't even compressed because
> their size is below Portage's size limit (which is 128 bytes IIRC).

Fair point. On your system all README.gentoo could be inlined by btrfs.

You also say that compression does not make a difference for all files 
on your system, as a whole 4 KiB block will likely be used anyway. We 
agree in the point that most README.gentoo files are small, because they 
should be suitable as output in pkg_postinst.

Doesn't this tell us that excluding README.gentoo from compression we be 
ok-ish?


>> Considering this, the 4-byte hash file is superior under the right
>> circumstances when compared to excluding README.gentoo from
>> compression. And I could imagine that the circumstances are right for
>> many of our users.
> 
> I very much doubt this.
> 
> In any case, the above size considerations aren't important. My main
> point is that the code is getting way too complicated for the simple
> task of printing a few lines in pkg_postinst.

Agreed. Even though you oversimplify the task. It's not just printing 
and installing a readme file. It's also comparing the contents of the 
current file with the new one.

And yes, "docompress -x README.gentoo" would make the code muuuuuuuuch 
simpler. And, as additional benefit, would help us get rid of storing 
the whole content of the readme in a environment variable (which is what 
readme.gentoo-r1.elcass currently does). Hence this is what was 
previously suggested, until people complained about it.

It seems like we are going in circles… :(

- Flow


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 17797 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]