[Development] Pending decisions on co-installation

[Oswald Buddenhagen]

this is just re-iterating stuff, but whatever.

On Tue, Oct 30, 2012 at 01:47:03PM -0700, Thiago Macieira wrote:
> 1) QML environment variables
>
+1

> 2) QML tool names
>
0

> 3) library versioning (i.e., adding "5" to the library name)
>
-1

renaming is unnecessary:
- there is no problem at all at run-time
- the problem at build time is solved by -L flags. there is no need for
  an unversioned symlink in /usr/lib.
renaming is a bit disruptive:
- projects not done with qmake need adjustment/ifdefs
  - but then, they probably need adjustment anyway due to the libraries
    having been split, etc.

otoh, we probably should rename the .pc files. this does *not* imply
renaming the libraries, except that it's less work with qmake, and you
already have done it.

so not having definite arguments either side, i'd lean to the status
quo. but feel free to try making a strong case in favor of change.

> 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.
> 
-2

it's just pointless to change the defaults (because it's trivial for
distros to adjust the paths, and diversity does not hurt in any way),
and it's counterproductive to introduce inconsistency in the defaults
between installed and non-installed builds.

the -archdatadir option as such does not hurt, but it introduces a
backwards-incompatibility (projects which don't use it on a system which
uses different dirs will fail to find the data). i'd prefer to postpone
this to The Next Real Major Version ™.

> 5) executable split between end-user applications and indirect tooling
> [...]
>
-2

> This proposal has met with vehement opposition and I'd like to hear why.
> 
as others pointed out, the split is arbitrary, and - given your wrapper
- just unnecessary.

> Finally, I am not listing the separation of paths for QML 1 and 2, since I 
> have not heard opposition to that fact. If I'm wrong, do speak up.
> 
+2
the relavant patch is delayed only because of the dependency on 4.

regards