Package: gcj-3.0 Severity: normal Hi,
An upcoming release of Debian policy, version 3.5.5.0, contains an amendment which clarifies the way man pages need to be installed. Until now, packages could install /usr/share/man/man1/foo.1.gz with 'foo, bar \- programs to do something' in the NAME section and have no corresponding symbolic link from bar.1.gz (policy suggested using a symbolic link, but wasn't clear that it's required), and our man program happened to magically figure it out for itself and display the right man page when you typed 'man bar'. However, guaranteeing that this would work even when you've recently installed some new packages has a serious performance impact on man, as it frequently has to go and look through the filesystem to update its database. Before woody's base system is frozen, I intend to remove this "feature" from man-db, so that its performance is consistent and acceptable for a reasonable number of people. It isn't a standard feature even among the various man page browsers in Debian, let alone in other Linux distributions, so there should be no compatibility problems. However, your package seems to rely on it, so this bug is being filed to let you know that the way some of your man pages are installed needs to be improved in order to work properly in woody. All you need to do, if you already have, say, foo(1) and expect bar(1) to work as well, is install a symbolic link to foo.1.gz as bar.1.gz (.so links and hard links are also OK, though symlinks are recommended). Here's a list of man pages and the names that don't appear anywhere in the filesystem: usr/share/man/man1/gcj-3.0.1.gz: gij If the list looks odd, please check man(7) to see if the man page is formatted properly. This output was generated by way of mandb, so if it's confused then users will be too; if it turns out that it's done the wrong thing, please reassign this bug to man-db so that I can fix it. I might not have caught symlinks that are created in the postinst (say, using alternatives); if that's the case, please close this bug. Please see bug #94995 and policy 3.5.5 section 13.1 for more information, and feel free to contact me if you need help. Thanks, -- Colin Watson, via a script
