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.
BSD/Linux anyone?
Another alternative might be star. However, I guess there is no way around GNU tar. For instance, with very long file names, GNU tar has its own format (unless something has changed meanwhile – I have not checked in the previous years). Since GNU tar is the de facto standard, it might cause enormous difficulties in this respect to change the default implementation.
The “own format” is actually POSIX (pax) and bsdtar supports it completely, which is why bsdtar is an usable replacement (while star isn’t).
Well, I just ran into this one screwing with my kde builds… Seems like this is one to be hard-masked?
http://code.google.com/p/li…“Stable release: libarchive-2.8.4.tar.gz libarchive-2.8.4.zipWorks on most POSIX-like systems (including FreeBSD, Linux, Solaris, etc.) “
so are you saying that there is sth wrong in the way tar works, if you have gcc 4.5.1 and app-arch/tar-1.23-r2 ?
No, 1.23-r2 is fixed for what concerns GCC 4.5, but it’s fixed locally in Gentoo. 1.22 through 1.24 are all broken in the same way for what concerns buffer overflows.But both 1.23 and 1.24 suffer from a number of bugs with some of their options.
GNU is a wrong and a closed idea, @Free (Free Software) is just enough for mostly users.
actually star is POSIX 1003.1 compliant and supports PAX, so i think it can be consider as an alternative
Since Gentoo also offers a BSD kernel, I think it would be wrong to call Gentoo anything but Gentoo.I personally *run* Gentoo GNU/Linux, though: I manage my GNU/Linux system with Gentoo.Is the bug for the KDE tarballs the one which spews garbage into my KDE install?
It would definitely be cool with some sort of linux distro variant out there that dared to implement alternative (BSD, Heriloom, p9p or whatever) tools to those of GNU. Not that I dislike GNU as such, but I think that diversity and competition is a good thing.A recent cool development is that LLVM/Clang can compile Linux:https://github.com/brycelel…The only remaining GNU tool that Linux is absolutely dependent on is ld, which he seems to be interested in finding alternatives to.so perhaps a “Clangtoo” project should be started as a (funtoo?) playground exploring the waters sort of like ClangBSD?