On Mon, 04 Sep 2023 13:54:18 +0100, Jeremie Courreges-Anglas wrote: > Two code sets are currently guarded with #ifdef SMALL in pax(1) and > tar(1): reading 'pax' format extended headers, and identifying various > compressed formats for user-friendliness. As noted by Caspar, the SMALL > path isn't currently used on the install media. I've been confused by > this twice already... > > Here's a proposal: > > 1. always compile in read support for the 'pax' format extended headers. > The ustar format is limited and being able to restore archives using > the pax format in any situation would be nice. Especially if we > switch to writing out pax format archives by default one day. > We're definitely not there yet.
Agreed. > 2. actually use -DSMALL to save a bit of storage on the install media. > The behavior is still sane, tar(1) warns that it doesn't recognize > a compressed archive, seeks through it trying to look a tar header, > and eventually gives up. Here's the tiny size change on amd64: > shannon /usr/src/distrib/special/pax$ size tar.o options.o pax obj/tar.o > obj/options.o obj/pax > text data bss dec hex > 6821 0 40 6861 1acd tar.o > 7195 1084 32 8311 2077 options.o > 390495 19024 85392 494911 78d3f pax > 6821 0 40 6861 1acd obj/tar.o > 6878 1084 32 7994 1f3a obj/options.o > 390175 19024 85392 494591 78bff obj/pax > > I don't expect any regression on the ramdisks but a make release is > running just in case. Sure, nothing relies on that anyway. - todd
