On 02/27/2012 09:59 AM, Calvin Morrison wrote:
Here is a solution.
Don't offer symlinks. Force users to memorize very minor changes in a few
differnet programs. If their scripts don't work - it will be pretty obvious why.
In our release announcement we will not what has changed.
One thing that bugs me about Trinity is the fear of any change whatsoever. Yes
we want to continue the KDE3 tradition, no we are not exactly kde3. If we make
changes, users will have to adjust.
It is better to force them to learn the new names then down the road having more
nasty issues with symlinks and packaging and a whole mess of crap that isn't a
good idea.
Calvin
I'm not adverse to change -- I have fully embraced kde4....
Seriously,
The issue isn't 'change' -- it's about 'smart change'. The
symlink issue is a
crutch - yes, but it is a necessary one until the entire codebase and
applications can be updated to use the new names.
CASE-IN-POINT - twin-style-crystal will not build because the
${TDEDIR}/lib/kde directory has been renamed ${TDEDIR}/lib/trinity. With the
complex build wizardry now used in building (libtools/cmake/take your pick) it
is not a simple 'grep some-changed-name some-source.c' to find the hardcoded
link. The problem may not even be in the source, but instead, some crazy
submodule somewhere...
If symlinks will provide a way to alleviate build or runtime issues until the
source and build system can be completely verified and fixed to use the renamed
files/locations, then I think they server a valid temporary purpose.
Just my .02 and not an argument against changing anything.
--
David C. Rankin, J.D.,P.E.