To me it makes more sense to scope this to either just Fedora or just when /tmp is tmpfs. I'm open to input from @Homebrew/maintainers, though.

Can we detect where to put this somehow?

I don't think we want to detect it every time we run the brew script. And Debian is moving to having in-RAM /tmp, like most distros already do: https://linuxiac.com/debian-13-moves-to-tmpfs-for-tmp-directory/

However, I would note that moving the temporary directory to /var/tmp means that things will be slower for most users. That's a significant downside.

just when /tmp is tmpfs.

Can we detect where to put this somehow?

This can be done with findmnt --target /tmp --output fstype --noheadings. It uses findmnt(8), which is in util-linux.

However, I agree with @fxcoudert. This is already the default behavior in just about every RPM-based distro and in Arch Linux and it will be soon in Debian

However, I would note that moving the temporary directory to /var/tmp means that things will be slower for most users. That's a significant downside.

Could you explain why for those of us not familiar with Homebrew internals?

moving the temporary directory to /var/tmp means that things will be slower for most users

The reason why /tmp is faster than /var/tmp is that it is RAM-based, rather than disk-based.

moving the temporary directory to /var/tmp means that things will be slower for most users

The reason why /tmp is faster than /var/tmp is that it is RAM-based, rather than disk-based.

Agreed. That's a pretty bad downside.

I see three solutions:

• catch the "No space left on device" error, and fallback to /var/tmp for a second attempt
• check the installed size upfront and if it will use too much RAM fallback to /var/tmp before installing
• ignore this edge-case (maybe document it as unsupported) / or require 8 Gb? of RAM to use Hombrew on Linux for those systems?

How about: catch the ENOSPC and suggest the user set HOMEBREW_TEMP to a suitable space?

The reason why /tmp is faster than /var/tmp is that it is RAM-based, rather than disk-based.

I would be cautious about assuming that applies to all operations without supporting evidence. While I’m not familiar with every use of HOMEBREW_TEMP, based on my benchmarking, I’ve found that the performance of brew install is identical whether using /var/tmp or /tmp.

Untarring and decompressing from disk into memory and then writing those files back to disk doesn’t result in any performance improvement compared to simply untarring directly onto disk and renaming afterward — at least when both the source and destination are on the same file system.

I would be cautious about assuming that applies to all operations without supporting evidence. While I’m not familiar with every use of HOMEBREW_TEMP, based on my benchmarking, I’ve found that the performance of brew install is identical whether using /var/tmp or /tmp.

Maintaining the status quo doesn't require supporting evidence, proposing a change does.

An argument in favour of this change: this makes things more similar to macOS and we've never had serious complaints about the status-quo there.