On Sat, 2024-01-06 at 18:01 +0100, Florian Schmaus wrote:
> I really like the functionality of readme.gentoo-r1.eclass, as it
> allows to communicate Gentoo-specific information about a package to
> the user. Especially as it improves the signal-to-noise ratio of
> messages arriving to our users.
> 
> However, readme.gentoo-r1.eclass will only show this information on
> new installs, but not if the information changed. This is a major
> drawback. Furthermore, readme.gentoo-r1.eclass does not provide an API
> to assemble the information via heredoc.

Are you implying that readme.gentoo-r1 is unfixable and you need to
start over, and have a third generation of eclasses to install a readme
file?

> The main item is doc compression. Right now, greadme.eclass defaults
> to add the readme doc to the compression exclusion list via
> "docompress -x". A mode where the readme doc is compressed, just as
> readme.gentoo-r1.eclass does, can be activated by setting
> _GREADME_COMPRESS. However, I believe this mode is fragile as it can
> not be guaranteed that a binary for the used compression algorithms is
> installed on the host [1].

Dangling reference here.  In any case, documentation compression is
a standard feature of the package manager.  If it doesn't work for
whatever reason, I'd rather see you focus on find a good solution rather
than working it around via abusing `docompress -x`.  It's basically
a case of "standard feature X doesn't work for me sometimes, so I now
randomly disable X via my eclass, and hope nobody notices".

> I believe it is reasonable to simply install the readme doc
> uncompressed, since they are typically only a few lines long. However,
> if anyone can point out a way to achieve the desired functionality with
> a compressed readme doc, then please let me know.

The compression mechanism automatically detects when the file is too
small to be worth compressing.  See PORTAGE_DOCOMPRESS_SIZE_LIMIT.


-- 
Best regards,
Michał Górny