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
signature.asc
Description: This is a digitally signed message part
