On 18 October 2012 17:23, Olivier Goffart <[email protected]> wrote: > Take the most recent example of python. They did not rename the executable. > Some distribution renamed the new one to python3, some other (archlinux) > renamed the old one python2. > Let the distributions solve the distributor's problem.
With the net result that a script with a #!/usr/bin/python , written for python2, now calls python3 and may break? Hasn't it happened to qtjsbackend / qtwebkit? This is a moot point. Distributions don't support multiple versions of Firefox, as it's an ordinary end-user application, therefore there's no problem there. If an user wants to install multiple, system-wide versions of Firefox, then has to figure out how to do that on his/her own. Some distributions do support multiple versions of GCC by installing them in different paths AND having different executable names in /usr/bin, with "gcc" or "g++" symlinks. But distributions don't support multiple versions of libc, multiple versions of libgcc, etc. It's reasonable to estimate that distributions will have to support coinstallation of Qt 4 + Qt 5 for the next 5-7 years. It's reasonable that the Qt project will have to support Qt 4 + Qt 5 for the next N years. What's our cost in renaming tools+libs now, once for all, versus the cost for every packager to rename/move things and test that they still work? What's our cost in documenting "call qmake5" (which will work everywhere) vs. documenting "call qmake" and getting feedbacks such as "it doesn't work" "what does qmake -v say" "Qt 3"? Cheers, -- Giuseppe D'Angelo _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
