Re: Re: [PATCH 0/9] Introduce esplit.eclass and port to it

--93SatMVJF3nmGS2v
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 10, 2026 at 07:59:37PM -0400, Ionen Wolkens wrote:
> On Fri, Jul 10, 2026 at 11:09:51PM -0000, Duncan wrote:
> > Sam James posted on Thu,  9 Jul 2026 22:22:09 +0100 as excerpted:
> >=20
> > > Introduce a new eclass (esplit.eclass) and port ebuilds to it. This is
> > > needed to unblock a Portage release with sandboxing for the 'depend'
> > > phase enabled, because the uses of a heredoc replaced here always
> > > require a temporary file with < EAPI 9 (and with >=3D EAPI 9, they do=
 but
> > > for large inputs only).
> >=20
> > Just to ask, since "with >=3D EAPI 9" has unlimited scope that could be=
 with=20
> > us for awhile and the vagueness of "large" accordingly disturbs me...
> >=20
> > Is it possible to better define "large" in "large inputs only"?
> >=20
> > Are we talking "large" in terms of lines, characters, ...?  Is it on th=
e=20
> > order of 1K lines/characters?  Just 10 (hopefully lines in that case)?=
=20
> > 100K?  GiB size?
>=20
> As I understand it (no expert), either the value of fnctl's
> F_GETPIPE_SZ determined at runtime if possible (e.g. on Linux) or
> PIPE_BUF at build time in bytes, which values vary depending on the
> operating system.
>=20
> On linux, this seems to be 64kiB minus 1 -- you can check with e.g.:

Minor correction, it is exactly 64kiB, not minus 1.

A <<<"" heredoc from the test below inserts a terminating newline.

>=20
> $ strace bash -c "read <<<\$(printf '%*s' 65535 '')" 2>&1 | grep /tmp
> <no output, aka no tmp file used>
>=20
> And then we do +1...
>=20
> $ strace bash -c "read <<<\$(printf '%*s' 65536 '')" 2>&1 | grep /tmp
> newfstatat(AT_FDCWD, "/tmp" [...]
>=20
> (note that can test the EAPI=3D8 behaviour by setting BASH_COMPAT=3D5.0,
> it should make both cases report /tmp usage)
>=20
> In global scope we don't (and shouldn't) operate on anything overly
> large -- typically it's only version strings, a package name or such.
> Things like large crate lists are worse but they wouldn't reach
> 64kiB still, if they do we really should re-arrange to avoid that not
> just because of this.
>=20
> Albeit I read MacOS may go as low as 512 bytes, so I dunno how that may
> work out on prefix -- but not sure how/if the same type of sandboxing
> is used there.
>=20
> >=20
> > And should such justification be in the eclass (in-eclass documentation=
,=20
> > or possibly just in the git commit comment) itself or is the series cov=
er-
> > letter alone discoverable enough in terms of people "archaeologically"=
=20
> > looking for the reason it was introduced, a decade or whatever from now?
> >=20
> > --=20
> > Duncan - List replies preferred.   No HTML msgs.
> > "Every nonfree program has a lord, a master --
> > and if you use the program, he is your master."  Richard Stallman
> >=20
> >=20
>=20
> --=20
> ionen



--=20
ionen

--93SatMVJF3nmGS2v
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQFPBAABCAA5FiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmpRiNYbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJELJEBrCwrEM0MK0IAJf2x3gBYMjHHVVxQL23
JRq7M5u5+fUERe69npYDy3rcaU0OUDuPjni2slJRS3REXAYm6hjMdGAl3EyhJV7T
s2EXrLRNl5b/l7H47GLzQ/+5aBUGk+y4UsFCLjux7WtgSN11Ea012eGtOmdvjp14
maRd+rTMpyPoIemwUG/+QtcoHsbbgrTmaofj6amZvT+0SpuyIXLD0aGKw+ozZcGE
veJBaSc2Q+ZsGKgCu1jGSyn2mj53XF7QQbJ1wQBW0olSljkZXqzrMIJB2KlpcdEr
qADZqmT/Mv7Qoe0V1lDJPgAPzDhRteIg7OudHehrwJe7iMu+3TtzoIk0pVzGGuH6
69c=
=rN96
-----END PGP SIGNATURE-----

--93SatMVJF3nmGS2v--