Hi anonymous reviewer,
R0b0t1 <r03...@gmail.com> writes:
> What is it intended to solve?
To simplify ebuilds that need to call eprefixify.
> The current behavior seems to make more sense. Hiding defaults causes
> problems.
I am not sure what you mean by "Hiding defaults". It is documented, not
hidden.
The regular expression
"s,([^[:alnum:]}])/(usr|etc|bin|sbin|var|opt)/,\1${EPREFIX}/\2/,g"
is conesrvative. And it will be scrutinized by the community.
Most files can be trivially prefixified by this regular expression.
Traditionally, we need generate a patch with @GENTOO_PORTAGE_EPREFIX@,
apply the patch and then eprefixify the source (which was
"s|@GENTOO_PORTAGE_EPREFIX@|${EPREFIX}|g"). We need a lot of such
trivial patches and it is not version-bump-proof.
Having a sane default improves maintainability. That's the point of
ebuild helpers and eclasses.
> `fprefixify` is redundant.
No, it's not redundant. An example of fprefixify is attached.
Benda
--- a/app-shells/bash/bash-4.3_p42-r2.ebuild
+++ b/app-shells/bash/bash-4.3_p42-r2.ebuild
@@ -88,11 +88,7 @@ src_prepare() {
epatch "${FILESDIR}"/${PN}-4.3-mapfile-improper-array-name-validation.patch
epatch "${FILESDIR}"/${PN}-4.3-arrayfunc.patch
- epatch "${FILESDIR}"/${PN}-4.0-configs-prefix.patch
- eprefixify pathnames.h.in
- # modify the bashrc file for prefix
- cp "${FILESDIR}"/bashrc "${T}"/ || die
- eprefixify "${T}"/bashrc
+ fprefixify epatch "${FILESDIR}"/${PN}-4.0-configs-prefix.patch
epatch_user
}
@@ -183,7 +179,7 @@ src_install() {
insinto /etc/bash
doins "${FILESDIR}"/bash_logout
- doins "${T}"/bashrc
+ fprefixify doins "${FILESDIR}"/bashrc
keepdir /etc/bash/bashrc.d
insinto /etc/skel
for f in bash{_logout,_profile,rc} ; do
