man pages suggest info pages that don't exist.

 status Confirmed

Local fix:

a) just remember to type "info coreutils ls" when you really want to type "info ls". Uugh.

OR

b)

cd /usr/share/info
sudo gunzip coreutils.info.gz
sudo vim coreutils.info

    comment out (delete?) the first "END-INFO-DIR-ENTRY" and
    second"START-INFO-DIR-ENTRY" lines.
    I used "##" as comment strings.

sudo gzip coreutils.info
sudo install-info --debug --infodir=/usr/share/info -- coreutils.info

Attached is a debdiff that implements the "other" solution (fixing the references in the manpages from "info <foo>" to "info coreutils <foo>").

The debdiff also includes a fix for bug #55991.

Micah Cowan said the following on 11/08/06 12:09:
> Attached is a debdiff that implements the "other" solution (fixing the
> references in the manpages from "info <foo>" to "info coreutils <foo>").
>
> The debdiff also includes a fix for bug #55991.
>

Micah, thanks. But I prefer my solution :). I think the man pages are
correct. I think it's the info pages which are broken.

The behaviour I'm looking for is what I had and am used to on redhat and
gentoo previously.

P.S. my chmod page doesn't have that regex, so perhaps that's been fixed.

--
Regards,

Jonathan Clark

Hi foolishchild,

Yeah, I understand you're point. And you're probably right (though, IIRC, Fedora Core uses the "info coreutils ls" version, which is why I did it that way: also, I thought it was closer to the upstream's intentions, but on closer investigation I don't believe that any longer).

However, editing the info file seems clearly the wrong way to go (.texi would be more appropriate), especially with the sort of hack where you take two sections and pretend they're one (also, your attached .info.gz file is wrong for the current version of coreutils, 5.96).

The .texi/.info files already /have/ the appropriate section ("Individual utilities"): the solution should probably be to fix the post-install scripts so they stick this section in there along with the "Basic" one.

Okay, I found the problem.

GNU's install-info (ginstall-info) sees both direntries and installs them both. Debian's just uses the top one. Sounds like the bug should be assigned to dpkg (containing Debian's install-info).

(adding /Baltix/'s dpkg was not intentional...)

See also bug #79459 which is filed against the texinfo package regarding the install-info problem.

Marking as confirmed. Does anyone know the reason for dpkg having its own version of install-info? And why it can't just be dropped in favor of gnu's version?

Rejecting the coreutils bug, as the bug is dpkg's, and a temporary fix does not appear necessary, as Debian has announced its intentions to migrate to GNU install-info

Phillip posted the same query regarding dpkg's versus GNU's install-info to debian's dpkg discussion list (to which I also am subscribed), and I was delighted to see the response that the intention to migrate to GNU's had been announced: http://lists.debian.org/debian-dpkg/2007/04/msg00031.html

Good man Micah.
I'm glad to see you are still on the case.

Micah Cowan said the following on 04/05/07 22:18:
> Phillip posted the same query regarding dpkg's versus GNU's install-info
> to debian's dpkg discussion list (to which I also am subscribed), and I
> was delighted to see the response that the intention to migrate to GNU's
> had been announced: http://lists.debian.org/debian-
> dpkg/2007/04/msg00031.html
>

--
Regards,

Jonathan Clark

Heh, thanks Jon, but I really can't claim to have been doing anything other than sitting on my butt on this one... I've just been waiting 'til I had enough time to give it proper attention; Phillip's the one who went to make an inquiry this time, and it appears that others have also been working on a solution for a bit now.

But yeah, I'm at least interested in seeing the documentation's statement as to what the right way is to find the infopage, be the right thing again :)

Ping!

I just discovered this bug when I read the man page for mkfifo and then tried to read the info for mkfifo.

I followed foolishchild's advice:

cd /usr/share/info
sudo gunzip coreutils.info.gz
sudo vim coreutils.info

    comment out (delete?) the first "END-INFO-DIR-ENTRY" and
    second"START-INFO-DIR-ENTRY" lines.
    I used "##" as comment strings.

sudo gzip coreutils.info
sudo install-info --debug --infodir=/usr/share/info -- coreutils.info

And now the problem is solved, at least for my box.

Should we consider putting this workaround in place for now, while we wait for the better fix?

Please observe that coreutils.info is inconsistent with the manual page for 'date'.

To reproduce: info 'coreutils' 'date'
Expected result: node 21.1
Actual result: node 27

Hi all,
  Read & did the workaround, I see still an issue when I try to get info about dpkg

I tried info dpkg > sends me to the dpkg manpage
           info coreutils dpkg > sends me to the coreutils.info node but nowhere else.
           info 'coreutils' 'dpkg' > "
           info coreutils 'dpkg invocation > "
           info 'coreutils' 'ls' > I get the right invocation 'ls'

So can anybody guide how can I get it or 'dpkg' is not there in coreutils.info ?

yecril71pl , where are u doing this ?

If I do info coreutils 'date invocation'

I get 21.1 `date': Print or set system date and time

while doing info 'coreutils' 'date'

I do get 27 Date input formats

but both of these are two different things, they are/maybe related but talk of different things I guess. Can u re-check & see if the differences are there or not.

@Shirish Agarwal: no, dpkg is not a part of the coreutils package. Perhaps you mean "date" or some other command?

The 'date' inconsistency should arguably be filed as a separate bug.

Shirish! {info 'date'} should display node 21.1 because that is what {man 'date'} suggests.
era! I cannot see any process in Launchpad to bifurcate a bug.

> era! I cannot see any process in Launchpad to bifurcate a bug.

Just submit a new bug and provide the bug number for this bug as background info if you think it's pertinent.

Thanks! Its an actually important thing. If you look for some answers, its necessary that the link that man gives must be real and keep them up to date.

Note also bug #248215 which notes the quotes in the man pages telling you to run info are smart quotes which can't be cut and pasted which confuses things further.

Dave

This has been corrected, at least on coreutils 7.10 (not available on Ubuntu Jaunty, since it depends on trunk automake to build).

"info coreutils 'chmod invocation'" returns the correct info page; the same happens with "info coreutils chmod", or "info coreutils 'chmod'".

Upstream has standardised on "info coreutils 'command invocation'", as a general rule.

I am also rejecting the dpkg tasks, since they have nothing to do with this issue.

hggdh, did you even read the thread? dpkg has everything to do with this issue. In particular, Debian's own custom version of "install-info" (part of the dpkg package) was the problem. That said, I understand Debian's moved to GNU's install-info, and I'm actually surprised that the problem doesn't appear to be fixed in Intrepid. Probably is in Jaunty.

darn it, I missed *just* this one comment :-(

Well, now that Micah corrected me, I went and looked for it. Here is what I see:

hggdh@xango2:/tmp/temp $ dpkg -S /usr/bin/ginstall-info && apt-cache policy texinfo
texinfo: /usr/bin/ginstall-info
texinfo:
  Installed: 4.11.dfsg.1-4
  Candidate: 4.11.dfsg.1-4
  Version table:
 *** 4.11.dfsg.1-4 0
        500 http://archive.ubuntu.com intrepid/main Packages
        500 http://archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status
hggdh@xango2:/tmp/temp $ dpkg -S /usr/sbin/install-info && apt-cache policy dpkg
dpkg: /usr/sbin/install-info
dpkg:
  Installed: 1.14.24ubuntu1
  Candidate: 1.14.24ubuntu1
  Version table:
 *** 1.14.24ubuntu1 0
        500 http://archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status
     1.14.20ubuntu6.1 0
        500 http://archive.ubuntu.com intrepid-updates/main Packages
     1.14.20ubuntu6 0
        500 http://archive.ubuntu.com intrepid/main Packages
hggdh@xango2:/tmp/temp $

So we are still using dpkg's install-info. As such, reopening upstream and Ubuntu's dpkg.

Well, we are back to this. At least on Karmic (and, probably, since Jaunty), /usr/bin/install-info (installed as part of the install-info package) is a wrapper to call GNU's install-info (if outside of a maintainer's script), or to flatly refuse to execute install-info (if called from within a maintainer's script).

So, I guess this is not an issue anymore. But, given my actions here, I will defer to Micah.

I'm only using Jaunty, and can't seem to find a install-info package there; but given that the core issue (documentation not matching reality) is resolved already, and based on this new statement, I'd consider it closed. (Also, the coreutils bit should probably already have been closed, right?)

Hi Micah,

After I updated this (and asked for your input), we found that only Karmic has the fix. The 'install-info' package is new, and only available on Karmic.

And, yes, the coreutils task should -- in my view -- have been set to Invalid: install-info is *not* a coreutils package, at least nowadays; I do not know how it was before (before being < ~2008, when I started looking at coreutils issues). Now, both 'ginstall-info' and 'install-info' are in the 'install-info' package... but if I run 'ginstall-info --help' I get a "Please report bugs to <email address hidden>". Since the versions on both the texinfo package and on ginstall-info match, I would guess it was originally there.

The message issued when you run (from the command line) '/usr/bin/install-info' says:

This is not dpkg install-info anymore, but GNU install-info
See the man page for ginstall-info for command line arguments
install-info: No input file specified; try --help for more information.

Whereas /usr/sbin/install-info is still the dpkg version...

So, it seems to my humble self that this is still a temporary bypass, and eventually dpkg's version will be dropped.

> And, yes, the coreutils task should -- in my view -- have been set to Invalid:
> install-info is *not* a coreutils package, at least nowadays

That was never the reason this bug was filed against coreutils; it was because the symptom (invalid forward pointer in the manual page) was manifest in coreutils. But I believe that part has been fixed now, based on comments above; although on my Jaunty box, e.g. the chmod manual page still says "info chmod" rather than "info coreutils 'chmod invocation'". Micah, do you have any indication in which version of the coreutils package this is supposed to have been fixed? (It does appear to be fixed in 7.4-2 which is the latest build for Karmic.)

Jaunty carried coreutils 6.10, as Intrepid did (and Hardy, if I remember correctly). As I noted some time back, at least as early as coreutils 7.10 it was already corrected.

The current version in Ubuntu is 7.4-2. It is indeed corrected in that, so the fix appeared sometime between 6.10 and 7.4-2. Perhaps this is sufficient for now; the fix will be included in Karmic.

This was indeed fixed in Karmic's dpkg.

  [ Raphaël Hertzog ]
  * Replace install-info by a wrapper around GNU's install-info. The wrapper
    will be dropped in squeeze+1. dpkg now Breaks: old versions of
    info-browsers that do not depend on the new install-info package
    that provides the real functionality. Closes: #9771, #523980
    See http://wiki.debian.org/Transitions/DpkgToGnuInstallInfo for details.

See also bug #630326