Re: strange man behavior
On Mon, Mar 30, 1998 at 09:56:07PM -0500, Dale Scheetz wrote:
> We seem to be having trouble communicating. As I have new information that
> bears on the root of this discusion, I suggest we table things as they are
> and look at the new data point.
good.
>
> I have had the manpages package installed for several days now and only
> just recieved the following:
>
> dwarf# man path
> Updating index cache for path `/usr/man'. Wait...man: warning:
> /usr/man/man7/undocumented.7.gz is a dangling symlink
> man: can't open /usr/man/man2/modules.2: No such file or directory
> man: warning: /usr/man/man2/modules.2.gz: bad symlink or ROFF `.so'
> request
> Updating index cache for path `/usr/man'. Wait...man: warning:
> /usr/man/man7/regex.7.gz is a dangling symlink
> man: can't open /usr/man/man3/regex.3: No such file or directory
> man: warning: /usr/man/man3/regex.3.gz: bad symlink or ROFF `.so' request
> done.
> No manual entry for path
>
> This is likely to be very troublesome to the new user.
Yes, it is also not so easy to find what caused that trouble.
The undocumented dangling symlink is caused by a missed dependency: package A
installs a symlink pointing to something installed to package B, therefore
package A must depend/suggest package B if B is not essential.
In this case it seems that we have to move the undocumented pages (I have a
dangling symlink to undocumented.9 on my hamm system) in a package marked
essential.
For the other warnings, it is difficult to know what happens, and you'll never
be sure to have cleared them all:
I have to admit that while writing this reply I discovered one "dangling"
manpage due to an error to one of my packages, so see how it's easy to create
those problems.
Anyway, I have far more of those warnings on my system, and I discovered now
that the update-alternatives is responsible of some of them:
man: warning: /etc/alternatives/ctags.1.gz is a dangling symlink
man: can't open /usr/man/man1/ctags.1: No such file or directory
man: warning: /usr/man/man1/ctags.1.gz: bad symlink or ROFF `.so' request
this is due to the fact that two packages uses update-alternatives to install
the same binary, but one declares a "slave" manpage (which produces a correct
symlink chain) while the other have no manpage (which breaks the chain).
I think we need to change the policy about this particular case, and maybe
also the behaviour of the tool. (well, not that the policy is wrong, but we
should enforce the use of the "undocumented" page in case of binaries without
manpages installed using update-alternatives, or force the use of the slave
option for binaries installed in the usual PATH)
the offending postinst is in emacs_19.34-13 (but it looks ok, while it is not
:-)
> I'm not suggesting that man-db should change its behavior...we just need
> to clean this up.
>
> Also note that this behavior only occures when a search is required that
> goes outside the database cache.
well, you get this behaviour when the pages are parsed to create/update the
database; this happens using mandb command, the -u --update flag of man, or
automatically when man finds a touched dir (as after installation of a
manpage).
> How do we clean up these links?
It is hard, because you have to investigate each one and try to find the
reason for that.
As I said above, there are cases in which nobody is guilty, and we must change
policy to get rid of the dangling link.
fab
--
| fpolacco@icenet.fi fpolacco@debian.org fpolacco@pluto.linux.it
| Líder Minimo del Pluto - Debian Developer & Happy Debian User
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
> more than 32 months are needed to get rid of the millennium. [me]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: