Re: CVS commit: src/external/bsd/libarchive/dist/libarchive

> Date: Mon, 24 Aug 2026 16:23:38 +0200
> From: Thomas Klausner <[email protected]>
> 
> So what's the best way forward?
> 
> pkgsrc sets
> ALL_ENV+=  LANG=C
> by default, and this now breaks unpacking on NetBSD-current for at least
> 
> devel/py-meson_python
> textproc/py-sphinx
> lang/go124
> devel/qt6-qttools
> 
> I see
> 
> a) do something about tar(1) in -current

This is likely to be a nonstarter unless there is an explicit option
instructing tar(1) to take the pax extended header `path' verbatim or
something.  We shouldn't diverge from upstream libarchive bsdtar
semantics unless we have an extremely compelling reason to do so.

(The patch I applied was to _reduce_ divergence from what upstream's
intent appeared to be, and I submitted it upstream for review in order
to make the semantics agree on more platfoms as verified by the tests:
<https://github.com/libarchive/libarchive/issues/3413>,
<https://github.com/libarchive/libarchive/pull/3416>.)

> b) do something about LANG=C in pkgsrc/mk

I suggest we set LC_CTYPE to a UTF-8 locale in EXTRACT_ENV for these
packages, if not also in ALL_ENV and/or likewise in all packages.

Previously discussed on tech-pkg@ in 2022, leading us to set
EXTRACT_ENV+= LC_CTYPE=en_US.UTF-8 in all packages on NetBSD<=8:

https://mail-index.NetBSD.org/tech-pkg/2022/05/05/msg026252.html
https://mail-index.netbsd.org/pkgsrc-changes/2022/05/21/msg254803.html

For NetBSD>=10, we can use C.UTF-8 instead of en_US.UTF-8 (though if
it's only for LC_CTYPE, using en_US.UTF-8 won't hurt, distressingly
angloyankocentric though that may be).

> c) extract them using gtar, which doesn't care

This is likely not reliable as noted at:
https://mail-index.NetBSD.org/tech-userlevel/2026/08/24/msg015063.html