[gentoo-dev] [PATCH 0/5] EAPI-8 support in gnome2{,-utils}.eclass

[gentoo-dev] [PATCH 0/5] EAPI-8 support in gnome2{,-utils}.eclass

[Marek Szuba]

EHLO,

Unless I have messed something up these are all the changes required
to make these two eclasses support EAPI 8. Comments welcome!
Nb. I am not the official maintainer of these eclasses, that said I did
discuss working on updating them for EAPI 8 with leio on IRC.

-- 
Marecki

[gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp

[Marek Szuba]

Has been deprecated for quite a while now, comes from eutils.eclass
so it blocks EAPI 8+. Just call mktemp directly.

Signed-off-by: Marek Szuba <marecki@gentoo.org>
---
 eclass/gnome2-utils.eclass | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/eclass/gnome2-utils.eclass b/eclass/gnome2-utils.eclass
index f7d45090f82..39c4797eedf 100644
--- a/eclass/gnome2-utils.eclass
+++ b/eclass/gnome2-utils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: gnome2-utils.eclass
@@ -16,10 +16,9 @@
 #  * scrollkeeper (old Gnome help system) management
 
 [[ ${EAPI} == 5 ]] && inherit multilib
-# eutils.eclass: emktemp
 # toolchain-funs.eclass: tc-is-cross-compiler
 # xdg-utils.eclass: xdg_environment_reset, xdg_icon_cache_update
-inherit eutils toolchain-funcs xdg-utils
+inherit toolchain-funcs xdg-utils
 
 case ${EAPI} in
 	5|6|7) ;;
@@ -379,7 +378,7 @@ gnome2_gdk_pixbuf_update() {
 	fi
 
 	ebegin "Updating gdk-pixbuf loader cache"
-	local tmp_file=$(emktemp)
+	local tmp_file=$(mktemp "${T}"/tmp.XXXXXXXXXX) || die "Failed to create temporary file"
 	${updater} 1> "${tmp_file}" &&
 	chmod 0644 "${tmp_file}" &&
 	cp -f "${tmp_file}" "${EROOT%/}/usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache" &&
-- 
2.32.0

[gentoo-dev] [PATCH 2/5] gnome2-utils.eclass: support EAPI 8

[Marek Szuba]

Trivial now that emktemp is gone.
While at it, include eclass name in the "EAPI x not supported" error
message.

Signed-off-by: Marek Szuba <marecki@gentoo.org>
---
 eclass/gnome2-utils.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/gnome2-utils.eclass b/eclass/gnome2-utils.eclass
index 39c4797eedf..97b845c7b88 100644
--- a/eclass/gnome2-utils.eclass
+++ b/eclass/gnome2-utils.eclass
@@ -4,7 +4,7 @@
 # @ECLASS: gnome2-utils.eclass
 # @MAINTAINER:
 # gnome@gentoo.org
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
 # @PROVIDES: xdg-utils
 # @BLURB: Auxiliary functions commonly used by Gnome packages.
 # @DESCRIPTION:
@@ -21,8 +21,8 @@
 inherit toolchain-funcs xdg-utils
 
 case ${EAPI} in
-	5|6|7) ;;
-	*) die "EAPI=${EAPI} is not supported" ;;
+	5|6|7|8) ;;
+	*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
 # @ECLASS-VARIABLE: GCONFTOOL_BIN
-- 
2.32.0

[gentoo-dev] [PATCH 3/5] gnome2.eclass: do not call xdg_src_prepare

[Marek Szuba]

No longer available for EAPI-8+, and gnome2_src_prepare already calls
xdg_environment_reset via gnome2_environment_reset. All that function
did otherwise was call default src_prepare for EAPI-6+ so do just that
directly.

Signed-off-by: Marek Szuba <marecki@gentoo.org>
---
 eclass/gnome2.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index 6fab55785be..4b7c3acac06 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: gnome2.eclass
@@ -96,7 +96,7 @@ gnome2_src_unpack() {
 # Prepare environment for build, fix build of scrollkeeper documentation,
 # run elibtoolize.
 gnome2_src_prepare() {
-	xdg_src_prepare
+	[[ ${EAPI} != 5 ]] && default
 
 	# Prevent assorted access violations and test failures
 	gnome2_environment_reset
-- 
2.32.0

[gentoo-dev] [PATCH 4/5] gnome2.eclass: standardise the EAPI guard

[Marek Szuba]

Signed-off-by: Marek Szuba <marecki@gentoo.org>
---
 eclass/gnome2.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index 4b7c3acac06..c6d93a46bfe 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -21,14 +21,14 @@ GNOME2_EAUTORECONF=${GNOME2_EAUTORECONF:-""}
 [[ ${EAPI} == [56] ]] && inherit eutils ltprune
 inherit libtool gnome.org gnome2-utils xdg
 
-case ${EAPI:-0} in
+case ${EAPI} in
 	5)
 		EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install pkg_preinst pkg_postinst pkg_postrm
 		;;
 	6|7)
 		EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install pkg_preinst pkg_postinst pkg_postrm
 		;;
-	*) die "EAPI=${EAPI} is not supported" ;;
+	*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
 # @ECLASS-VARIABLE: ELTCONF
-- 
2.32.0

[gentoo-dev] [PATCH 5/5] gnome2.eclass: support EAPI 8

[Marek Szuba]

Signed-off-by: Marek Szuba <marecki@gentoo.org>
---
 eclass/gnome2.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index c6d93a46bfe..0414d5cd5f3 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -4,7 +4,7 @@
 # @ECLASS: gnome2.eclass
 # @MAINTAINER:
 # gnome@gentoo.org
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
 # @PROVIDES: gnome2-utils
 # @BLURB: Provides phases for Gnome/Gtk+ based packages.
 # @DESCRIPTION:
@@ -25,7 +25,7 @@ case ${EAPI} in
 	5)
 		EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install pkg_preinst pkg_postinst pkg_postrm
 		;;
-	6|7)
+	6|7|8)
 		EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install pkg_preinst pkg_postinst pkg_postrm
 		;;
 	*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
-- 
2.32.0

Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp

[Michał Górny]

On Thu, 2021-12-09 at 13:23 +0000, Marek Szuba wrote:
> Has been deprecated for quite a while now, comes from eutils.eclass
> so it blocks EAPI 8+. Just call mktemp directly.
> 
> Signed-off-by: Marek Szuba <marecki@gentoo.org>
> ---
>  eclass/gnome2-utils.eclass | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/eclass/gnome2-utils.eclass b/eclass/gnome2-utils.eclass
> index f7d45090f82..39c4797eedf 100644
> --- a/eclass/gnome2-utils.eclass
> +++ b/eclass/gnome2-utils.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2020 Gentoo Authors
> +# Copyright 1999-2021 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: gnome2-utils.eclass
> @@ -16,10 +16,9 @@
>  #  * scrollkeeper (old Gnome help system) management
>  
>  [[ ${EAPI} == 5 ]] && inherit multilib
> -# eutils.eclass: emktemp
>  # toolchain-funs.eclass: tc-is-cross-compiler
>  # xdg-utils.eclass: xdg_environment_reset, xdg_icon_cache_update
> -inherit eutils toolchain-funcs xdg-utils
> +inherit toolchain-funcs xdg-utils
>  
>  case ${EAPI} in
>  	5|6|7) ;;
> @@ -379,7 +378,7 @@ gnome2_gdk_pixbuf_update() {
>  	fi
>  
>  	ebegin "Updating gdk-pixbuf loader cache"
> -	local tmp_file=$(emktemp)
> +	local tmp_file=$(mktemp "${T}"/tmp.XXXXXXXXXX) || die "Failed to create temporary file"

Why do you need to use random name in the first place?  We have full
control over T, so why not just hardcode a good name?

>  	${updater} 1> "${tmp_file}" &&
>  	chmod 0644 "${tmp_file}" &&
>  	cp -f "${tmp_file}" "${EROOT%/}/usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache" &&

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp

[Marek Szuba]

[-- Attachment #1.1: Type: text/plain, Size: 598 bytes --]

On 2021-12-09 15:04, Michał Górny wrote:

> Why do you need to use random name in the first place?  We have full
> control over T, so why not just hardcode a good name?

Having discussed the matter with eclass maintainers on IRC, they are not 
entirely sure whether using a static name in this context is entirely 
safe. There were also concerns about making this change too aggressive 
given it affects all supported EAPIs. Therefore, we have decided to play 
it safe and stick as closely to old behaviour as possible, at least for now.

Anyway, merged a moment ago.

-- 
Marecki

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp

[Mart Raudsepp]

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

Ühel kenal päeval, E, 13.12.2021 kell 10:19, kirjutas Marek Szuba:
> On 2021-12-09 15:04, Michał Górny wrote:
> 
> > Why do you need to use random name in the first place?  We have
> > full
> > control over T, so why not just hardcode a good name?
> 
> Having discussed the matter with eclass maintainers on IRC, they are
> not 
> entirely sure whether using a static name in this context is entirely
> safe. There were also concerns about making this change too
> aggressive 
> given it affects all supported EAPIs. Therefore, we have decided to
> play 
> it safe and stick as closely to old behaviour as possible, at least
> for now.
> 
> Anyway, merged a moment ago.

Actually I kind of preferred a static name over straight mktemp,
because emktemp supported other cases than a pure mktemp usage does.
But I don't know if it could ever clash things in some weird
situations. I think they won't, but I don't know if PMS guarantees that
or just happens how portage works right now (e.g. the postrm currently
happening in a separate ._unmerge directory path for $T; multilib
postinst happening sequentially, etc).

Thinking it through again a bit, straight mktemp can't be worse than a
static name anyways (provided mktemp exists, which emktemp handled..),
so we're good there, but provided you or someone thinks through the
corner-cases, I'm in favor of a static name if it doesn't have any
trouble.


Mart

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp

[Marek Szuba]

On 13 December 2021 17:24:18 UTC, Mart Raudsepp <leio@gentoo.org> wrote:

>Actually I kind of preferred a static name over straight mktemp,
>because emktemp supported other cases than a pure mktemp usage does.
>But I don't know if it could ever clash things in some weird
>situations.

That last part is the message I tried to convey in my e-mail, sorry if I wasn't clear enough.

Anyway, could anyone with more Postage/PMS experience weigh in on this? If it is indeed safe then the eclass could be modified further, e.g. to use static names with EAPI-8+ but stick with mktemp for older EAPIs just to be safe.

-- 
Marecki

Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp

[Michał Górny]

On Sun, 2021-12-26 at 09:44 +0000, Marek Szuba wrote:
> 
> On 13 December 2021 17:24:18 UTC, Mart Raudsepp <leio@gentoo.org> wrote:
> 
> > Actually I kind of preferred a static name over straight mktemp,
> > because emktemp supported other cases than a pure mktemp usage does.
> > But I don't know if it could ever clash things in some weird
> > situations.
> 
> That last part is the message I tried to convey in my e-mail, sorry if I wasn't clear enough.
> 
> Anyway, could anyone with more Postage/PMS experience weigh in on this? If it is indeed safe then the eclass could be modified further, e.g. to use static names with EAPI-8+ but stick with mktemp for older EAPIs just to be safe.

I suppose it's not specified strictly but T should be safe for all sane
uses.  If it weren't, we'd already be in deep trouble and gnome2-utils
would be the least of our concerns.

That said, making this EAPI-conditional is just an unnecessary
complexity.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp

[Mart Raudsepp]

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

Ühel kenal päeval, P, 26.12.2021 kell 10:50, kirjutas Michał Górny:
> On Sun, 2021-12-26 at 09:44 +0000, Marek Szuba wrote:
> > 
> > On 13 December 2021 17:24:18 UTC, Mart Raudsepp <leio@gentoo.org>
> > wrote:
> > 
> > > Actually I kind of preferred a static name over straight mktemp,
> > > because emktemp supported other cases than a pure mktemp usage
> > > does.
> > > But I don't know if it could ever clash things in some weird
> > > situations.
> > 
> > That last part is the message I tried to convey in my e-mail, sorry
> > if I wasn't clear enough.
> > 
> > Anyway, could anyone with more Postage/PMS experience weigh in on
> > this? If it is indeed safe then the eclass could be modified
> > further, e.g. to use static names with EAPI-8+ but stick with
> > mktemp for older EAPIs just to be safe.
> 
> I suppose it's not specified strictly but T should be safe for all
> sane
> uses.  If it weren't, we'd already be in deep trouble and gnome2-
> utils
> would be the least of our concerns.
> 
> That said, making this EAPI-conditional is just an unnecessary
> complexity.

It's already hardcoded to $T via using mktemp instead of emktemp (which
supported lack of $T or mktemp utility, unlike the replacement that was
merged) - so if $T and mktemp is guaranteed, we are good there. It was
introduced with mktemp in the first place and then vapier changed it to
emktemp without any reason given beyond probably just doing it for
everything to support lack of mktemp on the system or some such.


Now the question was, can we hardcode the name instead - is it possible
for it to be running things in parallel and clash on the name, e.g.:

* postinst and postrm ran at the same time on replacement: is it doing
._unmerge dir in portage an implementation detail that we shouldn't
rely on it?

* postinst and/or postrm ran with multilib support: could they be
running in parallel in the future for the different ABIs -- should we
include the ABI in the static filename at least to avoid clashes there?


Mart

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 981 bytes --]