On 1/20/26 9:37 AM, Matt Whitlock wrote: > This would be in the class of errors like std::logic_error from C++: > i.e., the programmer made a mistake in their code. I don't care if > the front falls off in this case since a mistake of this type would > be noticed and corrected by an ebuild author while testing their > ebuild, long before the ebuild ever hits any users. > > The other class of errors, which are like std::runtime_error, arise > from conditions that the programmer has no control over, which are > not due to incorrect code. For that class of errors, yes, I would > insist on the full suite of Portage's prettiness because such errors > are likely to occur on users' systems. > > You will note, I *did* say "at least." That left the door wide open > for more elaborate error handling. I only wanted to make sure that > the thing would noisily blow up rather than quietly generating a > file name lacking a unique identifier. The minimum possible demand > is more likely to be fulfilled.
This is NOT good developer UX for ebuild authors to debug and figure out
"what the heck is wrong with my machine":
>>> Emerging (1 of 1) dev-build/meson-1.9.1::gentoo
* meson-1.9.1.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ]
* meson-1.9.1.tar.gz.asc BLAKE2B SHA512 size ;-) ... [ ok ]
* meson-reference-1.9.1.3 BLAKE2B SHA512 size ;-) ... [ ok ]
>>> Unpacking source...
>>> Unpacking 'meson-1.9.1.tar.gz' to
/var/tmp/portage/dev-build/meson-1.9.1/work
=== Skipping unpack of 'meson-1.9.1.tar.gz.asc'
=== Skipping unpack of 'meson-reference-1.9.1.3'
* Verifying meson-1.9.1.tar.gz ...
INFO File
/var/tmp/portage/dev-build/meson-1.9.1/distdir/meson-1.9.1.tar.
gz verified successfully against the signature in
/var/tmp/portage/dev-build/meson-1.9.1/distdir/meson-1.9.1.tar.
gz.asc:
INFO - status: OpenPGPSignatureStatus.GOOD
INFO - valid: True, trusted: True
INFO - primary key: BD27B07A5EF45C2ADAF70E0484818A6819AF4A9B
INFO - subkey: 60411304C09D36628340EEFFCEB167EFB5722BD6
INFO - timestamp: 2025-09-22 17:52:35 UTC
/var/tmp/portage/dev-build/meson-1.9.1/temp/environment: line 3822:
notavar: parameter null or not set
* The ebuild phase 'unpack' has exited unexpectedly. This type of behavior
* is known to be triggered by things such as failed variable assignments
* (bug #190128) or bad substitution errors (bug #200313). Normally, before
* exiting, bash should have displayed an error message above. If bash did
* not produce an error message above, it's possible that the ebuild has
* called `exit` when it should have called `die` instead. This behavior
* may also be triggered by a corrupt bash binary or a hardware problem
* such as memory or cpu malfunction. If the problem is not reproducible or
* it appears to occur randomly, then it is likely to be triggered by a
* hardware problem. If you suspect a hardware problem then you should try
* some basic hardware diagnostics such as memtest. Please do not report
* this as a bug unless it is consistently reproducible and you are sure
* that your bash binary and hardware are functioning properly.
>>> Failed to emerge dev-build/meson-1.9.1, Log file:
>>> '/var/log/portage/build/dev-build/meson-1.9.1:20260120-150610.log'
* Messages for package dev-build/meson-1.9.1:
* Log file:
/var/log/portage/build/dev-build/meson-1.9.1:20260120-150610.log
* The ebuild phase 'unpack' has exited unexpectedly. This type of behavior
* is known to be triggered by things such as failed variable assignments
* (bug #190128) or bad substitution errors (bug #200313). Normally, before
* exiting, bash should have displayed an error message above. If bash did
* not produce an error message above, it's possible that the ebuild has
* called `exit` when it should have called `die` instead. This behavior
* may also be triggered by a corrupt bash binary or a hardware problem
* such as memory or cpu malfunction. If the problem is not reproducible or
* it appears to occur randomly, then it is likely to be triggered by a
* hardware problem. If you suspect a hardware problem then you should try
* some basic hardware diagnostics such as memtest. Please do not report
* this as a bug unless it is consistently reproducible and you are sure
* that your bash binary and hardware are functioning properly.
Furthermore, eclasses are *libraries* so per definition users use them
to make stuff, and "abnormal abort" is bad in API boundaries of library
code. This is not throwing a catchable user exception here -- this is
telling portage that bash exited in a manner "we don't understand, and
which *may* be a nonfunctioning binary".
bash has std::logic_error and it is called "die".
bash has abort() and it is called ":?" among other things. It is not
catchable, e.g. it will not run ERR traps. A C++ programmer would be
rightly scolded for producing a library that sanity checked its inputs
by calling abort() on API misuse.
"But the programmer made a mistake in their code. I don't care if the
front falls off in this case since a mistake of this type would be
noticed and corrected by an application author while testing their
program, long before the program is downloaded and compiled by any users."
--
Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
