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.