public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ulrich Mueller <ulm@gentoo.org>
To: Florian Schmaus <flow@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH v3 1/1] greadme.eclass: new eclass
Date: Thu, 13 Jun 2024 12:42:12 +0200	[thread overview]
Message-ID: <u1q51t98b@gentoo.org> (raw)
In-Reply-To: <2962cab0-a95d-48c0-b325-653364540326@gentoo.org> (Florian Schmaus's message of "Thu, 13 Jun 2024 12:18:51 +0200")

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

>>>>> On Thu, 13 Jun 2024, Florian Schmaus wrote:

>>> +_GREADME_DOC_DIR="usr/share/doc/${PF}"
>> It is somewhat unusual to call insinto or docompress with a relative
>> path. I'd use "/usr/share/doc/${PF}" here.
>> 
>>> +_GREADME_REL_PATH="${_GREADME_DOC_DIR}/${_GREADME_FILENAME}"
>> Why must this be a relative path? AFAICS it could be an absolute
>> path in
>> everywhere it is used. (You even add an explicit slash in places like
>> ${ED}/${_GREADME_REL_PATH}).

> My idea was to denote relative paths by not including an initial slash
> (/). This allows to write "${ED}/${_GREADME_REL_PATH}" without a
> duplicate slash in the middle. I find

> ${ED}/${_GREADME_REL_PATH}"

> more readable when compared to

> ${ED}${_GREADME_REL_PATH}"

I think the variable would be renamed in that case, i.e.
${ED}${_GREADME_PATH} or ${ED}${_GREADME_ABS_PATH}.

> which seems to be in-line with
> https://mgorny.pl/articles/the-ultimate-guide-to-eapi-7.html#d-ed-root-eroot-no-longer-have-a-trailing-slash

This has examples like ${D}${EPREFIX}/usr/share/foo: All path variables
start with a slash, _don't_ end with a slash, and no slash between them
when concatenating.

> But maybe I misunderstand what you are suggesting. You want

> _GREADME_DOC_DIR="/usr/share/doc/${PF}"

> instead of

> _GREADME_DOC_DIR="usr/share/doc/${PF}"

> right?

Correct.

> Then I'd also have to change to ${ED}${_GREADME_REL_PATH}", to avoid
> the double slash. :(

I see no problem with this.

>>> +	(
>>> +		insinto "${_GREADME_DOC_DIR}"
>>> +		doins "${_GREADME_TMP_FILE}"
>>> +	)
>> Why not a simple dodoc here?

> This was inspired by readme.gentoo-r1.eclass, which does

> 	( # subshell to avoid pollution of calling environment
> 		docinto .
> 		dodoc "${T}"/README.gentoo
> 	) || die

> I guess we could also switch to docinto & dodoc, but since we already
> need and have _GREADME_DOC_DIR, I went with that. Also the number of
> lines doesn't get any less.

> However, if you feel strongly about it, then I am happy to switch to
> docinto & dodoc.

I don't have any strong argument, dodoc just feels more approriate when
installing documentation.

> I did a last-minute change to that, which accidentally did not make it
> into the patch. This actually is now

> # @ECLASS_VARIABLE: GREADME_SHOW
> # @DEFAULT_UNSET
> # @DESCRIPTION:
> # If set to "yes" then unconditionally show the contents of the readme
> # file in pkg_postinst via elog. If set to "no", then do not show the
> # contents of the readme file, even if they have changed.
> ...
> if [[ -v GREADME_SHOW ]]; then
> 	case ${GREADME_SHOW} in
> 		yes)
> 			_GREADME_SHOW="forced"
> 			;;
> 		no)
> 			_GREADME_SHOW=""
> 			;;
> 		*)
> 			die "Invalid argument of GREADME_SHOW"
> 			;;
> 	esac
> 	return
> fi

> where I would argue that the [[ -v ]] test is sensible.

I'd still argue that empty should behave the same way as unset, but at
least with the explicit die there's no bad surprise for an empty value.

>>> +	while read -r line; do elog "${line}"; done < "${EROOT}/${_GREADME_REL_PATH}"
>> It is not guaranteed that the file exists in ${EROOT} at this point.
>> See FEATURES="nodoc" in make.conf(5).

> Fair point. Fixed.

Well, it still won't display anything with FEATURES=nodoc. IIUC
readme.gentoo-r1.eclass works around the problem by saving the file
contents in an environment variable. (However, I see the problem that
even then you couldn't compare old vs new file contents.)

> Thanks for your review. Adjusted accordingly
> (https://gitlab.com/flow/flow-s-ebuilds/-/commit/ef307612a676c7810e823ff6e38dac41bebd9dde).

Ulrich

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

  reply	other threads:[~2024-06-13 10:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-13  8:39 [gentoo-dev] [PATCH v3 0/1] greadme.eclass: new eclass Florian Schmaus
2024-06-13  8:39 ` [gentoo-dev] [PATCH v3 1/1] " Florian Schmaus
2024-06-13  9:31   ` Ulrich Mueller
2024-06-13  9:48     ` Ulrich Mueller
2024-06-13 10:18     ` Florian Schmaus
2024-06-13 10:42       ` Ulrich Mueller [this message]
2024-06-13 10:57         ` Florian Schmaus
2024-06-13 11:59 ` [gentoo-dev] [PATCH v3 0/1] " Ionen Wolkens
2024-06-13 12:53   ` Florian Schmaus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=u1q51t98b@gentoo.org \
    --to=ulm@gentoo.org \
    --cc=flow@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox