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. -- David C. Rankin, J.D.,P.E.