On Wed, 15 Feb 2012 23:26:01 +0200 Serghei Amelian serghei@thel.ro 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 :)