pkg/58863: devel/pkg-config logs are not written atomically

[dholland%NetBSD.org@localhost]

>Number:         58863
>Category:       pkg
>Synopsis:       devel/pkg-config 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 02:55: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
pkg-config 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 pkg-config source shows that it writes to the log
file with fprintf. Furthermore, it opens the log file with fopen(path,
"a") and historically/portably that doesn't use O_APPEND. 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
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...