Ü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 <l...@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
signature.asc
Description: This is a digitally signed message part
