Originally Posted by sinuhe
Posix compliance is the primary reason. Those who script to the standard will find things break on Slackware. This would seem to fit with Slackware's Unix-like focus.
Doubtful, using pax in scripts intended for use on Linux is a stupid idea given that almost no distro installs pax by default and those that do (or include it as part of an LSB compliance meta package) offer a poorly maintained fork of an old MirBSD pax. That version cannot even create pax archives
, only USTAR (and hence that pax is not POSIX.1-2001 compliant in any case). Furthermore the USTAR format is not a serious backup format for modern system due to various limitations, e.g. 8 GB limit on files within the archive. If you are writing scripts for use on Linux you should not rely on Pax being present, Posix requirement or not. Additionally I do not believe it is one of Slackware's goals to be 100% Posix compliant. Slackware is trying to stay true to the spirit of what UNIX is/was, not necessarily the latest iteration of Posix.
By the way modern versions of tar, like GNU tar and BSD tar can create Pax archives. Both of these versions have a wide range of options, vastly surpassing the feature set defined by Posix for Pax. The Pax format is IMHO a worthwhile standard, however the case for the pax binary is less clear. Tar has won that war and remains the de facto standard.
I say all of this as someone who actually has a soft spot for pax (it was a nice idea in theory). Indeed I maintain a SlackBuild for the pax provided by The Heirloom Toolchest
. This version of pax can create POSIX.1-2001 pax archives. It can also can read and write zip files, RPM packages, various tar formats (including GNU tar), and the extended cpio formats of Cray UNICOS, SGI IRIX (-K), SCO UnixWare (-c) and Tru64 UNIX (-e).