When tar is built with extended attribute support, the --xattrs option is not shown within the man page for tar. The option is shown when running 'tar --help'. Please let me know if this should instead be submitted upstream. Reproducible: Always
Upstream refuses to provide a man page and thus we decided a couple of years ago to maintain our own man page for tar. I already talked with vapier about this issue and he wants to go the same route Debian is doing by using a perl script to create a man-page from src/tar.c file in the tar source code. I gonna try to make a patch ready for our tar ebuilds which enables them to create a man page with aforementioned script.
Created attachment 361490 [details, diff] tar.diff Vapier, what do you think? Can we implement that? Is it okay to make tar ebuilds DEPEND on perl?
(In reply to Lars Wendler (Polynomial-C) from comment #2) > Created attachment 361490 [details, diff] [details, diff] > tar.diff > > Vapier, what do you think? Can we implement that? Is it okay to make tar > ebuilds DEPEND on perl? Not a good idea since tar is part of base, but perl is not. We purposely removed perl from base/packages to slim down the stages, this would pull it back in.
Although more difficult to maintain since there is no upstream or sidestream developing the script, would it be better to re-work the script into a bash and awk or even python script for build purposes?
(In reply to Anthony Basile from comment #3) > (In reply to Lars Wendler (Polynomial-C) from comment #2) > > Created attachment 361490 [details, diff] [details, diff] [details, diff] > > tar.diff > > > > Vapier, what do you think? Can we implement that? Is it okay to make tar > > ebuilds DEPEND on perl? > > Not a good idea since tar is part of base, but perl is not. We purposely > removed perl from base/packages to slim down the stages, this would pull it > back in. Well, another idea would be to create the man page for each new release once and provide that man page through FILESDIR. How about that? (In reply to m.cassaniti@gmail.com from comment #4) > Although more difficult to maintain since there is no upstream or sidestream > developing the script, would it be better to re-work the script into a bash > and awk or even python script for build purposes? Feel free to attach such a script to this bug. I don't have the time for looking into the perl script or else I'd already tried to turn it into a shell script.
+*tar-1.27-r1 (22 Oct 2013) + + 22 Oct 2013; Lars Wendler <polynomial-c@gentoo.org> -tar-1.27.ebuild, + +tar-1.27-r1.ebuild, +files/tar.1-1.27: + Added new man page (bug #488828), proper selinux (bug #488966) and acl + support. + I think best short term fix for now is to provide a man page created from Debian's perl script in FILESDIR. I took the opportunity to fix this as I already had to revbump tar-1.27 because of the above mentioned selinux bug. If you think this still isn't the best solution please open a new bug where we can find a better fix for the man page problem.
(In reply to Lars Wendler (Polynomial-C) from comment #5) > (In reply to Anthony Basile from comment #3) > > (In reply to Lars Wendler (Polynomial-C) from comment #2) > > > Created attachment 361490 [details, diff] [details, diff] [details, diff] [details, diff] > > > tar.diff > > > > > > Vapier, what do you think? Can we implement that? Is it okay to make tar > > > ebuilds DEPEND on perl? > > > > Not a good idea since tar is part of base, but perl is not. We purposely > > removed perl from base/packages to slim down the stages, this would pull it > > back in. > > Well, another idea would be to create the man page for each new release once > and provide that man page through FILESDIR. > How about that? That's the best way. > > (In reply to m.cassaniti@gmail.com from comment #4) > > Although more difficult to maintain since there is no upstream or sidestream > > developing the script, would it be better to re-work the script into a bash > > and awk or even python script for build purposes? > > Feel free to attach such a script to this bug. I don't have the time for > looking into the perl script or else I'd already tried to turn it into a > shell script.
Just looking at this bug report (https://bugs.gentoo.org/show_bug.cgi?id=382067) that discusses upstream support for ACL, SELinux and extended attribute support. I've checked the configure options for tar-1.27 and indeed the disable options are there for these three features. While were on the man page side of things, will these options also be included in the man page? I noticed that the current unstable tar-1.27 ebuild does not include acl and selinux USE flags. Should these be added? Should that be covered in another bug or the one I mentioned above?
(In reply to m.cassaniti@gmail.com from comment #8) > Just looking at this bug report > (https://bugs.gentoo.org/show_bug.cgi?id=382067) that discusses upstream > support for ACL, SELinux and extended attribute support. I've checked the > configure options for tar-1.27 and indeed the disable options are there for > these three features. > > While were on the man page side of things, will these options also be > included in the man page? > > I noticed that the current unstable tar-1.27 ebuild does not include acl and > selinux USE flags. Should these be added? Should that be covered in another > bug or the one I mentioned above? tar-1.27-r1 has all three USE flags (acl, selinux and xattr) as well as a new man page.
