[Development] Summary of renaming changes

[Thiago Macieira]

On sexta-feira, 19 de outubro de 2012 11.54.36, Joerg Bornemann wrote:
> On 18/10/2012 19:09, Thiago Macieira wrote:
> > Let me be very clear: the distributions aren't fixing the distribution's
> > problem. They'd be fixing *ours*.
> 
> Putting every binary into one directory excludes installing different
> versions of one binary. Obviously the coinstallation problem is unsolved
> for Linux distributions. Everyone is forced to do nasty workarounds
> where this could be solved in a proper way by agreeing on a standard.

Different versions of one binary but that retain backwards compatibility and 
purpose is not an issue. Those are rare cases anyway and, sure, tricks are 
often needed.

One case people keep bringing up is GCC. So let's talk about GCC.

When I last upgraded GCC from 4.6 to 4.7, it still compiled my programs. Where 
it didn't, it was usually broken code anyway. GCC developers reserve the right 
to fix bugs with their compliance with the C++ standard, just like we do 
reserve the right to fix bugs and change behaviour so long as we're still 
following our documentation.

So when I last upgraded GCC, it simply replaced the old one. "gcc" used to be 
4.6, now it is 4.7. The purpose is still the same: compile C and C++ programs.

The same can be said of, for example, CMake. Whenever there's an upgrade, from 
2.6 to 2.8, to 2.8.8, etc., it still performs the same functions. It still 
parses the same .txt files and loads the same scripts from  /usr/share/cmake. 
Their developers are actually quite careful about changing even small 
behaviour changes, which are triggered only by setting options (the policies).

But that can't be said of qmake. Upgrading qmake from Qt 4's version to Qt 5's 
changes it completely. It does not parse the same .prf files, they're not even 
in the same location! It does not serve the same purpose: that of compiling an 
application for Qt 4.

The qmake that comes with Qt 5 is serving an entirely different *purpose* than 
the one that came with Qt 3 or Qt 4. That's why it needs to be allowed to co-
exist with those others.

>    This *is* the problem of Linux distributions. FHS doesn't cover this
> problem properly and this is the point where it should be fixed.
>    You're making life harder for every platform - not only Linux - by
> fixing their problem.

You may argue that case, but they'll argue back that this solution has worked 
quite well for almost all packages for over a decade.

But I think that discussion is irrelevant and moot. The distributions will not 
change. If we fail to apply the fixes to our build, they will patch Qt and 
they've said as much on this mailing list. The end result of that is that they 
change *our* product, which means our documentation no longer applies to 
people who develop from packages, the help we give in #qt or other forums 
isn't entirely accurate.

What's more, they may introduce subtle bugs that may take a long time to be 
discovered. When tools like lrelease and lupdate fail to work, who will the 
users blame? Distributions or us?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121019/3e9038f5/attachment.sig>