On Wed, 15 Feb 2012 23:26:01 +0200 Serghei Amelian <serghei@...> wrote: > On Wednesday 15 February 2012 23:13:54 Darrell Anderson wrote: > > > > > Without renaming TDE must always exist in /opt on > > > > > > a system with Qt4, KDE4, > > > > > > > > or any KDE4 applications, and will never be able > > > > > > to be incorporated into > > > > > > > > any major distribution's main archives as a > > > > > > result. Furthermore, we have > > > > > > > > received explicit requests for some of the > > > > > > renaming from the original > > > > > > > > project's authors, and as I am not a lawyer I > > > > > > do not want legal trouble > > > > > > > > from using a name that belongs to a different > > > > > > project. Additionally, it > > > > > > > > can be very confusing to have libraries with > > > > > > identical names and > > > > > > > > completely different functionality; e.g. kdecore > > > > > > (TDE) vs. kdecore (KDE4). > > > > > > > You right, but better method to avoid conflicts is to > > > > > > prefix all relevant > > > > > > > libraries with tde- or trinity-, like tde-kdecore.so or > > > > > > trinity-kdecore.so, > > > > > > > etc. At least is consistent and predictable. > > > > > > The question is, will that be enough for the KDE people > > > who are requesting the rename? I think your suggestion might > > > be fine whilst R14 is in development, but I'm not so > > > sure about when it's released. It's best to either > > > ask to be sure, or to continue renaming. Besides, as I > > > understand it (I haven't been paying close attention), > > > the rename has been planned since before the git migration, > > > or at least shortly after, so the new names should not be a > > > surprise :-) > > > > I understand the frustration with the renaming. I too am sometimes > > frustrated by the renaming or the tqtinterface layer, especially > > when tracking bugs and needing to compare code to 3.5.10. > > > > Yet this is a frustration I'm willing to tolerate. As a long-term > > project goal, I would like to see everything renamed for the simple > > reasons that Trinity never would conflict with KDE4 and could be > > installed in /usr. Several bug reports I have submitted are related > > to installing Trinity in a non standard location or needing to use > > full pathnames to avoid KDE3/KDE4 apps of the same name. > > > > As a team we don't test for these conflicts. > > > > A complete renaming avoids potential legal issues too. > > > > I do have some grasp of the enormity of renaming everything. > > Currently I am editing and updating the user guides and just about > > every paragraph and web link needs attention. The same > > comprehensive approach would be needed to a complete renaming. > > > > I'm in favor of adding a complete renaming effort to the R15 goals. > > > > Many apps and shared library files can be renamed by transposing > > the "k" prefix with "t" or "kde" with "tde." I realize some apps do > > not lend well to that renaming (konqueror, kate, konsole, etc.). We > > likely will have to find a new name altogether. > > > > I understand and appreciate the adjustments all of us would have to > > make to rewire our minds to the new names. Not to mention > > exhaustive testing. Yet I think in the long run renaming everything > > is better. > > > > Darrell > > I'm not against renaming libraries or executables. But they should be > renamed in a consistent manner. I'm pretty sure that renaming > kdecore.so to trinity-kdecore.so should be enough. Do we really need to rename the .so files ? On my system: dd@darkstar:/usr/lib$ ls -l libkdecore* lrwxrwxrwx 1 root root 15 Dec 21 23:08 libkdecore.so -> libkdecore.so.5* lrwxrwxrwx 1 root root 19 Dec 21 23:08 libkdecore.so.5 -> libkdecore.so.5.4.0* -rwxr-xr-x 1 root root 2431824 Apr 11 2011 libkdecore.so.5.4.0* dd@darkstar:/usr/lib$ cd /opt/kde3/lib dd@darkstar:/opt/kde3/lib$ ls -l libkdecore* -rw-r--r-- 1 root root 754 Nov 4 20:22 libkdecore.la lrwxrwxrwx 1 root root 15 Nov 4 21:03 libkdecore.so -> libkdecore.so.4* lrwxrwxrwx 1 root root 19 Nov 4 21:03 libkdecore.so.4 -> libkdecore.so.4.2.0* -rwxr-xr-x 1 root root 2889852 Nov 4 20:42 libkdecore.so.4.2.0* We could have the libkdecore.so default (for example) to the KDE4 libkdecore.5.4.0, but still if we compile something against Trinity the dynamic linker would still use the libkdecore.so.4 file. It is/has been already done for libc and libstdc++, for example on my system: dd@darkstar:/usr/i486-slackware-linux/lib$ ls -l total 1944 lrwxrwxrwx 1 root root 18 Aug 8 2011 ldscripts -> /usr/lib/ldscripts/ -r-xr-xr-x 1 root root 272136 Feb 13 2010 libstdc++-3-libc6.1-2-2.10.0.so* -r-xr-xr-x 1 root root 274948 Feb 13 2010 libstdc++-3-libc6.2-2-2.10.0.so* lrwxrwxrwx 1 root root 31 Aug 8 2011 libstdc++-libc6.1-2.so.3 -> libstdc++-3-libc6.1-2-2.10.0.so* lrwxrwxrwx 1 root root 31 Aug 8 2011 libstdc++-libc6.2-2.so.3 -> libstdc++-3-libc6.2-2-2.10.0.so* lrwxrwxrwx 1 root root 18 Aug 8 2011 libstdc++.so.4 -> libstdc++.so.4.0.0* -rwxr-xr-x 1 root root 702796 Feb 13 2010 libstdc++.so.4.0.0* lrwxrwxrwx 1 root root 18 Aug 8 2011 libstdc++.so.5 -> libstdc++.so.5.0.7* -rwxr-xr-x 1 root root 732224 Feb 13 2010 libstdc++.so.5.0.7* Is there a gcc/ld option to tell it to link to libkdecore.so.4 if libkdecore.so points to libkdecore.so.5 ? > > Also, I want to keep untouched the name of header files and function > names. We really want to have applications which use Qt3 and Qt4 at > same time? I can't imagine this kind of mess :) > >