[Development] Pending decisions on co-installation

[Sune Vuorela]

On 2012-10-30, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 1) QML environment variables
> The variable for import paths has been versioned from QML_IMPORT_PATH to 
> QML2_IMPORT_PATH. But I have not changed any of the other variables. We need a 
> decision from the team familiar with the engines and the meanings of those 
> variables to know which ones should be versioned too.
>
> They need to be versioned if having a value set in it applies to one QML 
> engine but has ill-effects for the other.

isn't 'not versioning this' a recipe for disaster for both end users of
applications and for developers of applications if we don't do something

>
> 2) QML tool names
> Kai raised the point that many of the QML 2 tools work for QML 1 too and maybe 
> even for Qt 4's QML 1. We need confirmation on that as well as the willingness 
> to keep them that way for one or two years at least. For the tools that work 
> on both QML engines, we can drop the version number from their names.

ack.

> 3) library versioning (i.e., adding "5" to the library name)
> I'd like to see a decision here, one way or the other. I've posted my 
> arguments in favour more than once and I know there are people who disagree. 
> So let's hear from them why they disagree so we can see if there's a 
> consensus[*]. I'll similarly post the arguments in favour and I'd appreciate 
> if other people who agree did the same.

I would really like to see a '5' added. that way, people can use distro
packages and develop for qt4 on the same installation as they develop
for qt5. And this is very much going to be a issue.
the /usr/lib/libQtCore.so symlink can only point to one place at a time.

Alternatively, distributions will do something like that, and maybe even
do it differently and if we ar ereal lucky even break the much-valued
binary compatibility between installations - assuming that one distro
does libQt5Core, another does libQtCore5 and some just does a libQtCore.
The only way to prevent this is that we as Qt project (as oppsode to we
as packagers) actually does it. Having distro-qt's binary compatible
with upstream qt and other qt's (modulo fuckups) is a advantage.

> 4) new installation paths (besides the bin directory)
> The latest patch I've provided creates a grouping of all arch-dependent files 
> in ARCHDATADIR, with arch-independent files in DATADIR. That change, by itself, 
> is innocuous since it doesn't produce any difference in installation.
>
> The decision we need is on the defaults for those two directories. My proposal 
> is to have ARCHDATADIR=LIBDIR/qt5 and DATADIR=PREFIX/share/qt5 on Unix build 
> that require make install *only*. Again, there are arguments for and against, 
> so let's hear them.

For me, ensuring a 100% correct split between arch-dep and arch-indep
files isn't the most important issue, given that we, at a bit of a disk
space cost can put files where we are in doubt

> 5) executable split between end-user applications and indirect tooling
> The most controversial proposal so far is to split the binaries into two 
> groups: one that gets installed to PREFIX/bin, containing the executables for 
> applications run directly by the user and which retain backwards compatibility 
> of purpose, and one that gets installed to ARCHDATADIR/bin that contains the 
> tools that users generally do not run directly and which are specific to a 
> particular build of Qt. Please note that, in the current implementation, like 
> in #4 above, most people on this list will not see a change, as it applies to 
> Unix builds that require make install *only*.
>
> This proposal has met with vehement opposition and I'd like to hear why.

This is something that will happen to be done. and for the sake of
documentation and support, please let it be consistant not only across
distributions, but also across platforms so that documentations don't
have to be 
if mac | upstream-provided-linux-builds {
  run qmake
} else if windows {
  run qmake.exe
} else if debian {
  run qmake-qt5
} elese if fedora {
  run qmake5
}

Yes. we need to do something. and if the 'something' is to ask Lars as 
chief maintainer to override Ossi, then we must do that.

/Sune