Re: [gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass

[Ulrich Mueller <ulm@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

>>>>> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]