Tim, Darrell, All,
In the process of attempting to get the khelpcenter documents all collected in one spot in 3513-sru, I have found a simple setting that will allow both R14 and 3513-sru to standardize their document locations. The primary issue is that the base document path is hardcoded in tdelibs/kdecore/kstandarddirs.cpp on lines 1041-1042:
1041 if (!strcmp(type, "html")) 1042 return "share/doc/kde/HTML/";
All autotools build packages, on the other hand, set the equivalent path to:
return "share/doc/HTML/";
During April (10 & 11), Darrell fixed the R14 document locations. At that time there was no focus on 3513-sru as a branch. Instead of changing the hardcoded location in tdelibs to remove ../kde/.. to match all autotools package locations and changing the CMake files as originally envisioned, hundreds of individual patches were submitted to change all autotools acinclude.m4 files to move helpcenter docs from:
kde_htmldir='${datadir}/doc/HTML'
to
kde_htmldir='${datadir}/doc/tde/HTML'
That works fine for R14, but interjects incompatibility between R14 and 3513 essentially requiring 2-sets of hundreds of patches just to change the kde_htmldir to '${datadir}/doc/tde/HTML' (in the case of R14) and to '${datadir}/doc/kde/HTML' (for 3513).
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)
This would eliminate hundreds of patches required to change to 'tde' for R14 and to 'kde' for 3513 and move all sources back closer to their pristine state. This couldn't have been envisioned in April, but if we are serious about providing a 3513-sru branch and R14, then I think this is the right way to do it.
See: http://www.trinitydesktop.org/patches/ The set of commits at issue are between the following:
398ef116 2012-04-10 4e430ec6 2012-04-11
Thoughts?
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
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.
On Tuesday 21 of August 2012 18:58:01 David C. Rankin wrote:
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.
Interesting idea. The only thing that interferes with so far quite strictly held principle not rename k=>t. Please (others), what about this breach rules do you think?
Thanks Slavek --
On 08/21/2012 07:50 PM, Slávek Banko wrote:
Interesting idea. The only thing that interferes with so far quite strictly held principle not rename k=>t. Please (others), what about this breach rules do you think?
Thanks Slavek
Let's see what Francios says, but I have thought through this issue regarding a rename of kde_htmldir from ../doc/kde/HTML/<lang> to ../doc/tde/HTML/<lang>. I do not believe there were be any hidden or unanticipated consequences to any other packages or any other part of the build process. It is just the help dir locations.
I do TOTALLY are with the strictly held principle for 3513 not to rename k=>t anywhere it could possibly impact building. After wasting countless hours chasing k=>t build failures, it is critical that we stick to this principle.
Regarding the khelpcenter doc location, the benefits of the change do substantially outweigh any risks. Here we standardize the doc location for the entire GIT tree on ${datadir}/doc/tde/HTML/<lang>. That streamlines backporting of any future doc changes/additions from R14->3513. We lay the ground work for a future TDE install in /usr by insuring there are no doc conflicts with kde4 for all distributions (nobody and no other package will install docs to ${datadir}/doc/tde except TDE. There are no build considerations (i.e. renaming impacting build of other packages due to a k=>t change. Lastly, nobody cares what the actual directory name of the doc install location is as long as -- all the documents show up in khelpcenter. The dir could just as easily be named:
${datadir}/doc/thePlaceToInstallTrinityAppManuals/HTML/<lang> for that matter.
The key is that we standardize the location.
(1) Patch tdelibs to set kdecore/kdestandarddirs.cpp to point to the correct directory,
(2) Update the CMake files so that the apps building with CMake put the documents there, and
(3) Update the acinclude.m4 (or admin/acinclude.m4.in) files for all apps that build with autotools so that they put their docs in the correct place.
Then we are done with this issue once and for all. Darrell's set of commits should do this for 3513 and require nothing more than cherry-picking. (We need to make sure (1) above is done in his commits)
Otherwise, we end up with a distro-by-distro set of build-time hacks that are time consuming and difficult to maintain.
All things considered, I say we do this. Let's get a signoff from Francios and anyone else you think this change to 3513-sru will impact.
Le 22/08/2012 20:24, David C. Rankin a écrit :
On 08/21/2012 07:50 PM, Slávek Banko wrote:
Interesting idea. The only thing that interferes with so far quite strictly held principle not rename k=>t. Please (others), what about this breach rules do you think?
Thanks Slavek
Let's see what Francios says, but I have thought through this issue regarding a rename of kde_htmldir from ../doc/kde/HTML/<lang> to ../doc/tde/HTML/<lang>. I do not believe there were be any hidden or unanticipated consequences to any other packages or any other part of the build process. It is just the help dir locations.
I do TOTALLY are with the strictly held principle for 3513 not to rename k=>t anywhere it could possibly impact building. After wasting countless hours chasing k=>t build failures, it is critical that we stick to this principle.
Regarding the khelpcenter doc location, the benefits of the change do substantially outweigh any risks. Here we standardize the doc location for the entire GIT tree on ${datadir}/doc/tde/HTML/<lang>. That streamlines backporting of any future doc changes/additions from R14->3513. We lay the ground work for a future TDE install in /usr by insuring there are no doc conflicts with kde4 for all distributions (nobody and no other package will install docs to ${datadir}/doc/tde except TDE. There are no build considerations (i.e. renaming impacting build of other packages due to a k=>t change. Lastly, nobody cares what the actual directory name of the doc install location is as long as -- all the documents show up in khelpcenter. The dir could just as easily be named:
${datadir}/doc/thePlaceToInstallTrinityAppManuals/HTML/<lang> for that matter.
The key is that we standardize the location.
(1) Patch tdelibs to set kdecore/kdestandarddirs.cpp to point to the correct directory,
(2) Update the CMake files so that the apps building with CMake put the documents there, and
(3) Update the acinclude.m4 (or admin/acinclude.m4.in) files for all apps that build with autotools so that they put their docs in the correct place.
Then we are done with this issue once and for all. Darrell's set of commits should do this for 3513 and require nothing more than cherry-picking. (We need to make sure (1) above is done in his commits)
Otherwise, we end up with a distro-by-distro set of build-time hacks that are time consuming and difficult to maintain.
All things considered, I say we do this. Let's get a signoff from Francios and anyone else you think this change to 3513-sru will impact.
Hello, I think that changing the "kde" subfolder to "tde" subfolder by default is a good idea. As you say, we must ensure that all packages are updated to reflect that change, including the exotic ones (using scons or whatever else).
A quick thougt about the future install of TDE under /usr: I think the HTML files conflict is the easiest conflict to solve. We'll have much more troubles with binary conflicts under /usr/bin ...
Francois
Dne st 22. srpna 2012 Francois Andriot napsal(a):
Hello, I think that changing the "kde" subfolder to "tde" subfolder by default is a good idea. As you say, we must ensure that all packages are updated to reflect that change, including the exotic ones (using scons or whatever else).
A quick thougt about the future install of TDE under /usr: I think the HTML files conflict is the easiest conflict to solve. We'll have much more troubles with binary conflicts under /usr/bin ...
As you may have already noticed, all necessary patches have been backported. I have tested rebuild all Debian / Ubuntu packages and all looks good.
I hope this was one of last changes before release 3.5.13.1.
Slávek --
-
Darrell Anderson -
David C. Rankin -
Francois Andriot -
Slávek Banko