>>>>> On Wed, 10 Jan 2024, Florian Schmaus wrote: > On 10/01/2024 12.04, Sam James wrote: >> 1) The name seems odd (why not readme.gentoo-r2)? >> 2) Why can't the existing eclass be improved?
> Both points, the name of the eclass and the question if this should be > added to the existing eclass or as a new eclass, are absolutely *no* > hill I want to die on. > What I *really* care about is having the functionality that there is a > readme eclass that *also* shows the elog message if the README's > content changed (and not just on the first installation of the > package). Looks like readme.gentoo-r1 already gives you control over this: # If you want to show them always, please set FORCE_PRINT_ELOG to a non empty # value in your ebuild before this function is called. # This can be useful when, for example, DOC_CONTENTS is modified, then, you can # rely on specific REPLACING_VERSIONS handling in your ebuild to print messages # when people update from versions still providing old message. >> 4) The compression deal seems not worth bothering with. > Just to clarify: you are agreeing that excluding the readme doc from > being compressed is fine? Please respect the user's compression settings there. IMHO overriding them with docompress -x is a big no-no. > [...] > It exports phase functions, which readme.gentoo-r1 does not. Looking at the history, readme.gentoo[-r0] used to export phase functions: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/readme.gentoo.eclass?id=1e7b2242de29ec60105df1ef31939aed85a8b0eb#n32 It turned out to be a bad design choice, so -r1 no longer does that. > The readme.gentoo-r1 eclass always shoves the full content of the > readme into an environment variable. Why is this a problem? Ulrich
signature.asc
Description: PGP signature
