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 :)
> 
>