FS#39733 - [tar] 1.27.1-1 does not provide a proper man page

Attached to Project: Arch Linux
Opened by Patrick Goetz (pgoetz) - Thursday, 03 April 2014, 21:37 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Thursday, 01 May 2014, 19:38 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

The man page for tar is not the man page but rather a description of the tar file format. There will already be some confusion about the difference between bsdtar (which is actually libarchive tar and not BSD tar at all) and GNU tar. Not having a proper man page for tar adds to the confusion. There are differences which matter; e.g. GNU tar supports -d (--diff) while libarchive tar does not.


Additional info:
* package version: tar 1.27.1-1
This task depends upon

Closed by  Gerardo Exequiel Pozzi (djgera)
Thursday, 01 May 2014, 19:38 GMT
Reason for closing:  Upstream
Comment by Patrick Goetz (pgoetz) - Thursday, 03 April 2014, 21:38 GMT
I spent way too much time today puzzling through the (GNU) tar vs. (libarchive) bsdtar thing; mostly because

man tar

gave a bizarre answer. I strongly suspect other people coming from other distributions will have the same experience. Is this because upstream isn't supplying a man page? If so, this is a case where a distribution-specific patch (adding the man page) is highly warranted.
Comment by Karol Błażewicz (karol) - Thursday, 03 April 2014, 22:22 GMT Comment by Allan McRae (Allan) - Thursday, 03 April 2014, 22:43 GMT
No man page is provided by GNU tar. But one is provided by bsdtar (libarchive) which is what you are seeing. Not much to be done here...
Comment by Patrick Goetz (pgoetz) - Friday, 04 April 2014, 14:17 GMT
Hi -

I assumed that the reason there's no man page for GNU tar is because it's not being supplied by upstream. This seems like a case where a patch is warranted (i.e. this meets the criteria of stay as close to upstream *as possible*); namely just harvest the tar man page used by debian/red hat/etc. and add it to the package as a patch. Tar is a fairly critical piece of linux infrastructure, and as I mentioned, libarchive bsdtar and GNU tar are not feature identical. Some people have a lot of infrastructure built up around GNU tar and will be dismayed if they start migrating machines to Arch and find that there is no GNU tar man page. I have no idea why the FSF has a bug up their ass about man pages; probably still sore that the info system was never widely adopted. They should get over it; that battle was lost well over 10 years ago.
Comment by Dave Reisner (falconindy) - Friday, 04 April 2014, 14:28 GMT
info tar | less

There's your manpage.
Comment by Patrick Goetz (pgoetz) - Friday, 04 April 2014, 14:39 GMT
> info tar | less

That's more of a mantome. <:)
Comment by Dave Reisner (falconindy) - Friday, 04 April 2014, 14:45 GMT
Right, manpages are never long. Consider the manpages for at least: aria2c, bash, bzr, ccmake, cmake-gui, cmake, cmakemodules, cpack, ... (okay lots of cmake manpages), ex, multiple ffmpeg manpages, gcc, several perl manpages... These are all larger than the "man tome" generated from the info page, and this is only the start of what I could find on my local machine.
Comment by Patrick Goetz (pgoetz) - Friday, 04 April 2014, 14:56 GMT
Of course, I was just joking. We all know that man pages are a somewhat idiosyncratic convenience in an era where we can google "GNU tar" on our phone. The point is people expect to see a certain thing when they type `man tar` and will not be happy when that's not what they get. I'm the type of technology user who forgets syntax and uses `man command` constantly as a 2 second reminder. And the fix for this is entirely trivial; else, you're right; it wouldn't be worth bothering with.
Comment by Allan McRae (Allan) - Friday, 04 April 2014, 23:19 GMT
tar --help

The problem with using the Debian man page is that it is for a version that is always behind ours. New flags do get added and it is too much burden to update the man page.

GNU tar maintainers have specifically rejected a man page. This is an upstream decision and we should follow it.
Comment by Patrick Goetz (pgoetz) - Monday, 07 April 2014, 17:39 GMT
It probably wouldn't be too hard to have a little script which converts the info page to a man page. However, in the absence of doing something to create a legitimate man page for tar, I strongly suggest that what appears when you type

$ man tar

*not* be a description of the archival format (that's really confusing) but rather a stub which tells user's something like this:

---------------------------------------------------------------------
The FSF does not provide a man page for this application. Please try

info tar | less

instead, or consult https://www.gnu.org/software/tar/manual/
---------------------------------------------------------------------

I wouldn't have filed a bug report if this is what happened when I typed `man tar` myself.
Comment by Sébastien Luttringer (seblu) - Thursday, 17 April 2014, 23:04 GMT
Why do you open your BR downstream for this? Open a bug report to GNU Tar and request them to add your message, with a further explanation of why they don't want provide a man page. Every distro will benefit of that.
Comment by Patrick Goetz (pgoetz) - Thursday, 24 April 2014, 10:43 GMT
> Why do you open your BR downstream for this? Open a bug report to GNU Tar

Because I already know that they don't care and won't do anything about this. Debian requires a man page for everything, even if the man page is "there is no man page". This isn't a bad policy to follow.
Comment by Allan McRae (Allan) - Thursday, 24 April 2014, 11:48 GMT
Our policy is follow upstream decisions.
Comment by Patrick Goetz (pgoetz) - Thursday, 24 April 2014, 14:24 GMT
I've made my point and am going to request that this bug be closed. I can see both sides, but still believe that users would benefit from my April 7th comment; something which would hardly impose much of a burden on the package maintainer.

Loading...