>   Why not fix this once and for all, fix tdelibs, and just set:
> 
> kde_htmldir='\${datadir}/doc/HTML'
> 
> for all??

> That way, instead of patching hundreds of autotools
> packages, the original location in tdelibs is standardized where it should be in
> 'kstandarddirs.cpp', the CMake files are corrected to match the original
> kde_htmldir locations in their sources, and all future CMake migration can go forward
> without every set of files having to set kde_htmldir and reset it for 3513 in
> another set of patches... (this stuff should be standard anyway -- there is
> absolutely no need to have 'kde' or 'tde' in the middle of kde_htmldir)

Because adding the /tde/ (nee /kde/) subdirectory ensures there are no conflicts, real or imagined, with KDE3/KDE4.

By default KDE4 is hard-coded to install help files to share/doc/HTML. I checked the 4.8.5 source code.

You could modify only kstandarddirs.cpp and the cmake converted packages, but then risk conflict with KDE. That was my original proposal long ago too. Then I realized the potential conflict existed and only resolved one problem while creating another. Hence the eventual comprehensive change of all packages.

Generally, most packagers build TDE to install to /opt/trinity. Most packagers build KDE3/KDE4 to install to /usr. In that case there are no potential conflicts. Yet nothing stops packagers from building Trinity to install to /usr.

Short history:

In 3.5.10 kdelibs/kdecore/kstandarddirs.cpp, the path was set to share/doc/HTML/.

In SVN commit 1061230 (3.5.11) the path was changed to share/doc/kde/HTML/. This was the first attempt to avoid potential conflicts.

In GIT commit 979b0c9a the path was changed to share/doc/tde/HTML/, as part of the overall renaming project.

As noted, everything now installs correctly in R14. The problem is fixing 3.5.13 SRU. SRU needs to avoid the same potential conflict. Therefore leave kdelibs/kdecore/kstandarddirs.cpp as is, leave the cmake packages as is, and update the autotool packages. Backport the R14 patches.

SRU is not patched with the many renaming efforts and therefore should remain at share/doc/kde/HTML/, just like currently set in kdelibs/kdecore/kstandarddirs.cpp

The help handbook problem existed right from the beginning in 3.5.13 and never noticed by anybody. I don't know whether the problems existed in 3.5.12 or 3.5.11. I suspect they did because the autotool files never were updated to match the change made in SVN 1061230 (3.5.11).

I appreciate the desire to avoid work. Yet once the patches are in place the computers do all the work.

Your frustration right now is the same I experienced last year when I tripped over this problem. Small consolation, I know. :-)

Darrell