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 --]
next prev parent 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