On 08/20/2012 12:26 PM, Darrell Anderson wrote:
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
I see your point, but what else installs in /opt/trinity/share/doc? -- ever? Your approach does provide a solution for a future /usr install though -- that I do like...
We can also do a packaging/post-install fix on 3513:
cd /opt/trinity/share/doc/kde/HTML/en for i in ../../../HTML/en/*/; do ln -s $i; done
or
for i in ../../../HTML/en/*/; do mv $i .; done
(but that type of kludge looks bad...)
The way I looked at it was -- it was the same amount of work either way:
(1) create a duplicate set of commits for 3513 setting everything to /doc/kde/HTML/
(2) attempting to cherry-pick the R14 commits to put everything in /doc/tde/HTML/
or
(3) create a set of commits to standardize the entire GIT tree on doc/HTML.
If we are looking at some future /usr install, then (2) is the correct way to go.
Slavek, can you look at the 4/10, 4/11 commits and see if we can just apply those to 3513-sru and just pull all the docs in /doc/tde/HTML/? That would also accomplish standardizing doc locations between R14 and 3513. That would be the way to go -- all things considered.
Thanks.