From: Eli Schwartz <eschwartz93@gmail.com>
To: gentoo-dev@lists.gentoo.org, Michael Orlitzky <mjo@gentoo.org>
Subject: Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
Date: Wed, 13 Sep 2023 17:06:53 -0400 [thread overview]
Message-ID: <80d81d82-1c92-5841-aec3-2801d0284868@gmail.com> (raw)
In-Reply-To: <5e1996ebadf6bb3f0c49509bda63a703744d1099.camel@gentoo.org>
On 9/13/23 9:10 AM, Michael Orlitzky wrote:
> On Tue, 2023-09-12 at 22:52 -0400, Eli Schwartz wrote:
>>
>> Is portage generally expected to successfully complete (including
>> internal metadata write stages) when its workdir drive runs out of space
>> partway through?
>>
>
> No, but I think what everyone else is forgetting to mention is that if
> it's going to fail, we want it to fail as soon as possible, i.e. as
> close to the thing that actually went wrong. If we proceed past ENOSPC
> or whatever, we could get five or six lines further in the ebuild, and
> then some other command will fail but possibly with a crazy unrelated
> error message.
The consequences of this particular command failing are that:
- setuptools will still build, but without spawning a ThreadPoolExecutor
to distribute jobs; it builds single threaded
- setuptools will still build, but using its default build directory
instead of an alternative one; setuptools itself *cannot* fail as a
result, but other external commands hardcoding the location of
setuptools internal files could fail to find those files
(It will still fail when setuptools reports its own ENOSPC, but this is
not a crazy unrelated error message.)
(Unless portage expects to successfully complete where possible if the
workdir drive runs out of space partway through, then quickly has more
space freed up for it as soon as monitoring warnings are triggered and
no actually-fatal ebuild errors occurred during the window of ENOSPC.)
--
Eli Schwartz
next prev parent reply other threads:[~2023-09-13 21:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-12 19:14 [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options Eli Schwartz
2023-09-12 19:14 ` [gentoo-dev] [PATCH 2/2] python-utils-r1.eclass: unconditionally warn on occluded packages in cwd Eli Schwartz
2023-09-12 19:56 ` [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options Ulrich Mueller
2023-09-13 2:07 ` Eli Schwartz
2023-09-13 2:26 ` Michał Górny
2023-09-13 2:52 ` Eli Schwartz
2023-09-13 3:13 ` Sam James
2023-09-13 7:50 ` Alexey Sokolov
2023-09-13 13:10 ` Michael Orlitzky
2023-09-13 21:06 ` Eli Schwartz [this message]
2023-09-13 9:27 ` Ulrich Mueller
2023-09-13 21:06 ` Eli Schwartz
2023-09-14 8:24 ` Ulrich Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=80d81d82-1c92-5841-aec3-2801d0284868@gmail.com \
--to=eschwartz93@gmail.com \
--cc=gentoo-dev@lists.gentoo.org \
--cc=mjo@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox