I have sincere doubts when people insist on calling Gentoo a GNU/Linux distribution, mostly because we’re well versed in supporting non-GNU Free Software alternatives, even if sometimes it’s quite difficult to do so. One of the cases which I tried to tackle before and I failed was the ability to use bsdtar as system implementation of tar(1). Lacking a complete system like Debian’s alternative, and left with mostly-custom, identical scripts for eselect, supporting simply tar is trivial, supporting multiple implementations and tools really isn’t.
But why am I taking again the idea out right now? It’s not like the Google Summer of Code is approaching (well, there is Google Code-In but this is definitely not the kind of thing that could be done there. Instead, the reason why I approach the notion once again is that GNU failed us again: version 1.24 of GNU tar is bugged as the Fallout 3 vaults.
In a previous iteration I complained about GNU software not working properly with the new version of GCC (4.5). One of the software that failed to work as intended was, as you might have already guessed, tar. Indeed the new, stronger buffer overflow detection in GCC and GLIBC made sure that tar 1.22 and 1.23 (already released at the time) tried to run a strncpy() between two adjacent buffers. It was a known problem from before, but with the latest (for the time) toolchain updates, it became a failure situation.
You’d expect that version 1.24, released last week, would have applied the trivial fix needed. The answer is a resounding “nope”. D’oh!
Okay so whatever, they didn’t fix something, but it’s not the end of the world, is it? I’m still keeping around patches for Linux-PAM that I wrote years ago. Sure it is a bit worse because it’s the GNU project utilities refusing to update for the changes in the GNU project toolchain, but it’s nothing extreme.
What make it much worse is that this release actually introduces not one, but two bugs that hit us very hard; one relates to the very important -C switch; the other seem to relate instead to the KDE tarballs (that most likely are created with an older version of GNU tar itself). Somehow, it feels like the project could use a much more extensive testsuite.
Considering this and a number of other issues, I’m sincerely wondering if I shouldn’t be working again on making it feasible for users to choose bsdtar as default implementation (but still allow for side-by-side installation, since I’m sure there will be stuff not working properly with bsdtar at first), and set that up on the tinderbox as well. One of the nicest part of it, is that libarchive allows for in-process decompression and extraction (which GNU tar can’t do), and it would allow to replace two packages (GNU tar and cpio) with a single one, that is already required by both GNOME and KDE.