manpages-oops & malloc problem

[Mike A. Harris]

Donnie Berkholz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Kevin Day wrote:
> | First Problem:
> | I noticed that in your Changelogs, the man1x's were installed in man1
> (which
> | was fixed in rc3).
> | I then noticed that (in rc3 as well) man3x and man5x have the same issue.
> | They should be installing in man3x and man5x, but they are installing
> in man3
> | and man5.
> 
> In 6.8.99.15 and earlier, they installed into man1, man3, man4, man5,
> man7. No 'x' suffixes, although the actual manpages were named foo.1x.gz
> etc. This allows man to not change its search path.

Having the X manpages installed into the existing system manpage dirs
simplifies the configuration of man, by not having to add additional
directories to its configuration.

One side effect of this however, is that by doing this, we are moving
all X manpages from previously being installed into their own namespace,
to being installed in system namespace, which can cause manpage name
conflicts if any other software has existing manpages with the same name
as an X manpage.

The only specific example I'm aware of currently, is the mouse(4)
manpage, which exists in both X, and in the system man-pages package.
All of the X driver manpages are named the same name of the driver,
which is a convenience, so it would be nice to keep this convention
for the X driver manpages.  Another option would be to get the other
'mouse' manpage renamed in the upstream source for man-pages, however
the other page has been named that as long as I can remember.

Aside from this one example conflict though, it is theoretically
possible that other software out there has manpages with the same names
as X manpages, and nobody has encountered a conflict between them
before, since X manpages were installed in their own namespace.

In X11R6 if you do "man -a mouse", you get both manpages showing up,
which is good.  However if you have both foo.4 and foo.4x in the same
man4 directory, at least in Linux, man will only show the one manpage,
even if you do "man -a foo".

Personally I think that it is probably best to keep the X manpages in
their own namespace, and manNx directories seems to be the easiest
way to do that, however I also think it is easiest maintenance-wise
for distributors, to ship the manpages in the location that X.Org
installs them to by default, as it is currently not possible to
override the upstream location in any trivial way.  Currently, changing
the manpage install location involves hacking up the .m4 file that
defines the locations, and then either regenerating all the tarballs,
or running autoreconf on every single tarball, which is an effort
great enough to consider it something that is not intended by upstream
to be changed.

It's too late to fix this for X11R7.0 IMHO, and having a single known
manpage conflicting with another is rather small problem overall.

I think we should reinvestigate this for X11R7.1 however.  I think
the best solution would be one that provides X.Org to give a set of
default dirs, and default suffixes for all manpage sections, and have
that stored in a pkgconfig file.  Then have all of the other packages
read the mandirs/mansuffixes via pkgconfig.  This way a distribution
can customize the manpage install locations by making a single change
in one place, without having to make additional changes to all of the
other packages throughout the X release.  If people think this is
a reasonable solution, I'll go ahead and implement it in the new year,
and submit a patch.

Another possibility, would be having per-distribution tweaks for these
locations present right in the upstream packaging, as was done in
X11R6 et al. via the Imake linux.cf file.  LinuxDebian, LinuxRedHat,
LinuxSlackware, etc..

Thoughts/feedback, appreciated.  Happy Holidays everyone!



-- 
Mike A. Harris, Open Source Advocate  *  http://mharris.ca
Proud to be Canadian.