Gentoo Archives: gentoo-dev

From: Mart Raudsepp <leio@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp
Date: Sun, 26 Dec 2021 10:17:51
Message-Id: 3a8cfa13f644f63dcb996b1158c5714c8bdc53f0.camel@gentoo.org
In Reply to: Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp by "Michał Górny"
1 Ühel kenal päeval, P, 26.12.2021 kell 10:50, kirjutas Michał Górny:
2 > On Sun, 2021-12-26 at 09:44 +0000, Marek Szuba wrote:
3 > >
4 > > On 13 December 2021 17:24:18 UTC, Mart Raudsepp <leio@g.o>
5 > > wrote:
6 > >
7 > > > Actually I kind of preferred a static name over straight mktemp,
8 > > > because emktemp supported other cases than a pure mktemp usage
9 > > > does.
10 > > > But I don't know if it could ever clash things in some weird
11 > > > situations.
12 > >
13 > > That last part is the message I tried to convey in my e-mail, sorry
14 > > if I wasn't clear enough.
15 > >
16 > > Anyway, could anyone with more Postage/PMS experience weigh in on
17 > > this? If it is indeed safe then the eclass could be modified
18 > > further, e.g. to use static names with EAPI-8+ but stick with
19 > > mktemp for older EAPIs just to be safe.
20 >
21 > I suppose it's not specified strictly but T should be safe for all
22 > sane
23 > uses.  If it weren't, we'd already be in deep trouble and gnome2-
24 > utils
25 > would be the least of our concerns.
26 >
27 > That said, making this EAPI-conditional is just an unnecessary
28 > complexity.
29
30 It's already hardcoded to $T via using mktemp instead of emktemp (which
31 supported lack of $T or mktemp utility, unlike the replacement that was
32 merged) - so if $T and mktemp is guaranteed, we are good there. It was
33 introduced with mktemp in the first place and then vapier changed it to
34 emktemp without any reason given beyond probably just doing it for
35 everything to support lack of mktemp on the system or some such.
36
37
38 Now the question was, can we hardcode the name instead - is it possible
39 for it to be running things in parallel and clash on the name, e.g.:
40
41 * postinst and postrm ran at the same time on replacement: is it doing
42 ._unmerge dir in portage an implementation detail that we shouldn't
43 rely on it?
44
45 * postinst and/or postrm ran with multilib support: could they be
46 running in parallel in the future for the different ABIs -- should we
47 include the ABI in the static filename at least to avoid clashes there?
48
49
50 Mart

Attachments

File name MIME type
signature.asc application/pgp-signature