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 |