I believe that DNF is not formatting a scriplet's error. May be RPM team will know little bit more.

Is that the literal error message? I dunno about dnf and it's libraries, but there's no such message in rpm:

> [pmatilai🎩︎localhost rpm]$ find -name "*.c"|xargs grep "Cannot create"
> [pmatilai🎩︎localhost rpm]$

(In reply to Panu Matilainen from comment #2)
> Is that the literal error message?

Yes, the literal error message in its entirety is:
    Cannot create temporary file - mkstemp: No such file or directory
as given in the Actual results section in the original report above.

>  I dunno about dnf and it's libraries, but
> there's no such message in rpm:

Perhaps the message is from Python?
    $ grep 'Cannot create'  $(rpm -ql $(rpm -qa | grep py)) 2>/dev/null  # no matches

    $ grep 'temporary file' $(rpm -ql $(rpm -qa | grep py)) 2>/dev/null  # interesting, including:
/usr/lib64/python3.9/tempfile.py:creating temporary files and directories.  All of the interfaces
/usr/lib64/python3.9/tempfile.py:             another candidate location to store temporary files.
/usr/lib64/python3.9/tempfile.py:    """Calculate the default directory to use for temporary files.
/usr/lib64/python3.9/tempfile.py:                          "No usable temporary file name found")
/usr/lib64/python3.9/tempfile.py:    """User-callable function to return a unique temporary file name.  The
/usr/lib64/python3.9/tempfile.py:                          "No usable temporary filename found")
/usr/lib64/python3.9/tempfile.py:    """A separate object allowing proper closing of a temporary file's
/usr/lib64/python3.9/tempfile.py:    temporary file."""
/usr/lib64/python3.9/tempfile.py:        Close the temporary file, possibly deleting it.
/usr/lib64/python3.9/tempfile.py:    """Create and return a temporary file.
/usr/lib64/python3.9/tempfile.py:        """Create and return a temporary file.

> Yes, the literal error message in its entirety is:
>    Cannot create temporary file - mkstemp: No such file or directory
> as given in the Actual results section in the original report above.

Ack, thanks for confirming. I thought the message was indeed literal because it was repeated twice as such, but had to make sure due to the nature of this bug (it's not rare for people to describe stuff from memory, with inevitable differences to actual messages). We can't fix in rpm what doesn't come from rpm.

My apologies for redirection the issue to RPM. I overlooked that the message is generated librepo util.c


```
int
lr_gettmpfile(void)
{
    int fd;
    _cleanup_free_ char *template = NULL;
    template = g_build_filename(g_get_tmp_dir(), "librepo-tmp-XXXXXX", NULL);
    fd = mkstemp(template);
    if (fd < 0) {
        perror("Cannot create temporary file - mkstemp");
        exit(1);
    }
    unlink(template);
    return fd;
}
```
It looks like that the variable TMPDIR is used by g_lib. I propose to modify message to include the path from template "Cannot create temporary file - mkstemp '/tmy/...'"

Then the final message will be something like "Cannot create temporary file - mkstemp '<path>': No such file or directory".

Anyway the issue has low priority, therefore community can help - link to repository and the file - https://github.com/rpm-software-management/librepo/blob/3b9a8d17188ba602d139f79b6e61305030f21109/librepo/util.c#L158

We consider the bug as a valid but because the issue has limited impact (low priority) we postpone the issue in favor of other issues.

Showing more detailed error message was implemented.

Following PRs were queued related to this fix:

fix:   https://github.com/rpm-software-management/librepo/pull/262
tests: https://github.com/rpm-software-management/ci-dnf-stack/pull/1148

Cloned into RHEL 9 ticket https://bugzilla.redhat.com/show_bug.cgi?id=2121663.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (librepo bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2981