From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id AE8B3158086 for ; Mon, 13 Dec 2021 17:24:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 501542BC019; Mon, 13 Dec 2021 17:24:34 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 931CDE075F for ; Mon, 13 Dec 2021 17:24:28 +0000 (UTC) Message-ID: <136a9c8c1a600ca22f4facdb8de8feb3ba0bb818.camel@gentoo.org> Subject: Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp From: Mart Raudsepp To: gentoo-dev@lists.gentoo.org Date: Mon, 13 Dec 2021 19:24:18 +0200 In-Reply-To: References: <20211209132325.297913-1-marecki@gentoo.org> <20211209132325.297913-2-marecki@gentoo.org> <1f731fd5d6309bf1ebeb8e08b73ca903a1bc47dc.camel@gentoo.org> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-mMrBuL5sZGBUspvs9PCl" User-Agent: Evolution 3.42.2 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: 6fa9c0a0-9051-4398-93aa-d92be049f788 X-Archives-Hash: bf30a439e6ccf7ce784e8219f01a6317 --=-mMrBuL5sZGBUspvs9PCl Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =C3=9Chel kenal p=C3=A4eval, E, 13.12.2021 kell 10:19, kirjutas Marek Szuba= : > On 2021-12-09 15:04, Micha=C5=82 G=C3=B3rny wrote: >=20 > > Why do you need to use random name in the first place?=C2=A0 We have > > full > > control over T, so why not just hardcode a good name? >=20 > Having discussed the matter with eclass maintainers on IRC, they are > not=20 > entirely sure whether using a static name in this context is entirely > safe. There were also concerns about making this change too > aggressive=20 > given it affects all supported EAPIs. Therefore, we have decided to > play=20 > it safe and stick as closely to old behaviour as possible, at least > for now. >=20 > 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 --=-mMrBuL5sZGBUspvs9PCl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQKTBAABCgB9FiEEUdZn9pOq0mlNjRvdEKbJ+k9JlgYFAmG3gcNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDUx RDY2N0Y2OTNBQUQyNjk0RDhEMUJERDEwQTZDOUZBNEY0OTk2MDYACgkQEKbJ+k9J lgbPmg//Wou6gVdzSJfgI+GnBq3smpe6b0q2l8DMCipZb1nCQIWNsj4Zl+1vO4WG ee4ojOVSkJtFxigJu0ZUrpRv2mVHL6RT2H4hIs/Z496NuPuoQUKKS8uFkYYLmqVu 24o14BRJlyMdPFPLqgwMV2qvRCyVXyy58Y/Rg9V7eg2NuhD4myxKaAAPPqeh8YFr ZZNE25tMt5gF2rP+j/jChgNuPzqx0R926PBbnNBS45L2tm4YY1NjVd1YmOUg6Zbr XwOBuY564l3oBPh1xXJxGayYIUhNlOBbQh4jz3bBIFfxoKnXXL0UP9lX98LRrwo4 ousb9QY74sIXThaWqU/BPLESsWjWI3AeItNi0JK1RnQeXv1brPEuxk0Hfu1+KUQh F2faxvNs44Qv8tXB6mtSeRUSyH09VVIG1oqhxUeFmehNXnpOJq0WbMNurrqtSfKn yZkK9FD/yy8glajxTeTvh3MywY8CZvXV9yG3YUyb0RS+MEkYUo4AbHe6NLB6PgvQ lCBfQIqtuzxvBUXFfer6xcALMe4LqAlN4BM98joiZezWGf4pom+W8d2aani1iWjy +v81hGSnZVuSCpeuAOV/or+ag0MW4ofGW47d15qeMbjpc7iDy4V7VP5PdziU03U8 oQcv/Fmu3Al+rg9IQdexyCoysPgHJBCFzjX/BRhGSgB3JyVZpDY= =VQKz -----END PGP SIGNATURE----- --=-mMrBuL5sZGBUspvs9PCl--