Page MenuHomeFreeBSD

Makefile.inc1: Only copy locales to INSTALLTMP on FreeBSD
ClosedPublic

Authored by ivy on Tue, Apr 28, 3:29 AM.
Tags
None
Referenced Files
F156941977: D56677.id176760.diff
Sun, May 17, 12:54 PM
F156910019: D56677.id176760.diff
Sun, May 17, 7:08 AM
F156909589: D56677.id176760.diff
Sun, May 17, 7:04 AM
Unknown Object (File)
Sat, May 16, 12:00 AM
Unknown Object (File)
Fri, May 15, 6:44 AM
Unknown Object (File)
Thu, May 14, 10:16 AM
Unknown Object (File)
Thu, May 14, 10:16 AM
Unknown Object (File)
Thu, May 14, 9:44 AM
Subscribers

Details

Summary

Makefile.inc1 copies locales to ${INSTALLTMP} to avoid issues when
running make installworld on a live system. However, this can break
on non-FreeBSD systems, e.g. on openSUSE where /usr/share/locales
has mode 0555, which means after we copy it, we can't delete it,
so the build fails.

Since this functionality is only useful when installing over a
live system, disable it when the build host is not FreeBSD.

Sponsored by: https://www.patreon.com/bsdivy

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

ivy requested review of this revision.Tue, Apr 28, 3:29 AM
Makefile.inc1
1484–1485

There's a PATH_LOCALE setting in one of the *ENV that should get similar treatment- I would suspect the variable is pretty specific to our libc (and Dragonfly, maybe Illumos and macOS), but probably better to be clear.

I'd also be supportive of your other proposal to avoid it if DESTDIR != /, though I don't know if you dismissed that idea entirely. I don't feel strongly about it...

only set PATH_LOCALE on FreeBSD

Makefile.inc1
1484–1485

i went through a couple of approaches here; i think ideally we should disable this entire feature, even on FreeBSD, when we aren't doing a live installworld, but that's a larger and more risky change... this is the least invasive change that fixes the Linux build in the mean time.

kevans added inline comments.
Makefile.inc1
1484–1485

Yeah, fair enough!

This revision is now accepted and ready to land.Tue, Apr 28, 2:03 PM

I think this is fine for now. I'd be happy to see DESTDIR-based changes later on.