pkg/58864: devel/pkgconf logs are not written atomically

[dholland%NetBSD.org@localhost]

>Number:         58864
>Category:       pkg
>Synopsis:       devel/pkgconf logs are not written atomically
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Nov 30 03:15:00 +0000 2024
>Originator:     David A. Holland
>Release:        NetBSD 10.99.10 (20240218) pkgsrc 20241110
>Organization:
Practical Porpoises, Inc.
for all your underwater engineering needs!
>Environment:
System: NetBSD valkyrie 10.99.10 NetBSD 10.99.10 (VALKYRIE2) #0: Mon Feb 19 02:27:48 EST 2024  dholland@valkyrie:/y/objects/usrobj/sys/arch/amd64/compile/VALKYRIE2 amd64
Architecture: x86_64
Machine: amd64
>Description:

I built ocaml-lablgtk3 just now specifically to run verifypc, and that
told me "verifypc: ro not a direct dependency", and sure enough
there's a "ro" in the pkg-config log. This is, as best I can tell, a
fragment of a line that was trying to log "cairo"; there is no
pkgconfig file for a "ro" package buildlinked (or anywhere on my
system) and the rest of the log entry indicates that _something_ was
found. In any event the behavior didn't repeat on a rebuild.

Inspection of the pkgconf source shows that it writes to the log file
with fprintf. Furthermore, it doesn't even open the log file with
fopen(path, "a"), so isn't getting even that rudimentary level of
protection against concurrent writes. And there's no attempt to lock
the file with flock or anything else. Between these points it's
surprising the log isn't garbaged up more.

This does only apply to otherwise MAKE_JOBS_SAFE packages that run
pkgconf/pkg-config during the build rather the configure step, but
there are probably a fair number of these.

It's also an upstream bug but we ought to reach some kind of internal
consensus on what we expect before complaining upstream.

>How-To-Repeat:

make

>Fix:

Use open with O_APPEND and a single write() for each line. Or collect
the log messages in memory and log them all at once. Or various other
things.

What we shouldn't do is mark all the affected packages
MAKE_JOBS_SAFE=no just because of a silly problem like this...