Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: The SUS/POSIX standard tool pax is required for LSB 3.2 compliance. The version of this tool on Linux (all systems I've tested) provide ustar format but not 'pax" format. "pax" format is required by LSB; it is needed to backup ACLs and extended attributes including SE Linux labels. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. try "pax -x pax" ... 2. 3. Actual results: pax: Unknown -x format: pax Expected results: should work. Additional info: libarchive does support pax format. It should be easy to create a front-end for pax that uses libarchive (which comes with bsdcpio front-end, but not in the Fedora 10 package). SUSv3 and SYSv4 (and POSIX all required this format to be supported, and LSB 3.2 does as well.) Not supporting it means no standard tool can make archives with EAs; more importantly it means Fedora (and presumably Red Hat) is not compliant with the LSB. Work-around: Install star or libarchive tar-ball (for bsdtar and bsdcpio). However using either tool won't make Fedora LSB compliant.
Thanks for report. Package pax in Fedora is based on SuSe Linux port of *BSD pax implementation. I checked the original OpenBSD pax implementation and they have pax -x pax support already implemented. I tried to port it(and fix compiler warnings/errors) on Fedora Rawhide today. Unfortunately it doesn't work correctly at the moment. Will try to figure out what's wrong as pax should follow POSIX specification.
Well, to clarify this - original OpenBSD implementation doesn't have that support implented. Only existing implementation I have found is from MacOSX. See for reference http://opensource.apple.com/source/file_cmds/file_cmds-202.2/pax/ ... None of Linux distros I know about has this part ported for Linux, my try to port it has about 2500 lines (and because there is no "alive" upstream for Linux port, it has to be maintained on Fedora side - in fact the patch/port is ready, but I doubt about it's quality, too many code duplicities and if0-ed/ifdef-ed parts there ). I incline to not include that format into pax and maybe suggest star for that format in pax manpage.
That support is really needed. A comment in the man page isn't the same!
Well, I know that comment is not the same like the support for that format. But initial OpenBSD implementation - upstream - doesn't include that format - yet. You may check that at http://www.openbsd.org/cgi-bin/cvsweb/src/bin/pax/ . Linux port was initiated by SuSe, but there is no change for ~5 years. And having the burden of maintaining additional format - which is still not implemented in upstream version - is probably unacceptable - 2500 lines of untested (and probably buggy - I tested that patch only a bit) ported implementation is really too much. Mentioning that pax unability with some explanation and pointing to star (which already does that implementation) is cheap and is worth of adding. At least as the temporary solution. There are already other archivers which do support extended attributes and acl's preservation - either Fedora tar or star.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Could the pax from the http://heirloom.sourceforge.net/tools.html be used instead? It supports the pax format.
(In reply to comment #8) > Could the pax from the http://heirloom.sourceforge.net/tools.html be used > instead? It supports the pax format. The AT&T AST OpenSource software collection [1] bring a lot of original UNIX tools/utils. And pax is included. [1] http://www2.research.att.com/sw/download/
I don't think that any of these projects can be used here. Pax package is just about the pax binary - and pax format is already provided in star. The only option might be to implement this format ourselves - as the SuSE upstream seems to be dead.
Possible solution for this could be the bug #929349 - use 'spax' as alternative. Discuss there please if you want, thanks.
Fixed in RAWHIDE. The 'pax' binary was moved as 'opax' (OpenBSD implementation of pax) in 'pax' package. This still provides /usr/bin/pax symlink. The package 'spax' delivers 'spax' binary, which is alternative pax implementation. The 'alternatives' are incorporated, thus 'spax' provides also 'pax' symlink. When both 'spax' and 'pax' packages are installed, 'spax' has a bigger priority. Spax should better conform to POSIX requirements. The package 'redhat-lsb' requires /usr/bin/pax binary, which installs then both 'pax' and 'spax' packages and the 'spax' should win in that case. If we want to be more specific, the 'redhat-lsb' could require only 'spax' package. Tested components: ~> pax-3.4-16.fc20.x86_64 ~> spax-1.5.2-3.fc20.x86_64 Pavel
> The package 'redhat-lsb' requires /usr/bin/pax binary, which installs then > both 'pax' and 'spax' packages and the 'spax' should win in that case. This is not a truth, I have created bugzilla to track this problem: https://bugzilla.redhat.com/show_bug.cgi?id=965658