[Development] Pending decisions on co-installation

[Thiago Macieira]

On quarta-feira, 31 de outubro de 2012 12.23.27, Oswald Buddenhagen wrote:
> > 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.

Ossi: let me ask you something then: do you want our make install to manage 
both /usr/lib *and* /usr/lib/qt5/lib?

If so, we need to know about both build dirs and therefore we need --
prefix=/usr on installations.

If not, I am going to require you to write a script for distros installing 
each Qt tarball so that they do the right thing for each library and it does 
not hardcode anything.

My argument is that the split is necessary because we're being asked to manage 
all of this. I'm also with Ján here that trying to override the default search 
paths is troublesome. Some less sophisticated buildsystems might add -
L/usr/lib64 due to other dependencies saying that is necessary, then all of a 
sudden the application will start linking to Qt 4.

(on OpenSUSE) $ mysql_config --libs                                    
-L/usr/lib64 -lmysqlclient -lpthread -lz -lm -lrt -lssl -lcrypto -ldl

Mark my words: this is a recipe for disaster.

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

The only thing that uses DataDir is qmake, to find its mkspecs. Also, quite 
clearly QLibraryInfo is about Qt itself. Other libraries and applications have 
no business using those paths. Therefore, I argue that:

1) they shouldn't store their files there
2) if they are using to read some Qt files, the only ones affected are the 
mkspecs, which require quite an updated parser anyway.

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

Ok, then let's see what your proposal is:

All of our executables are installed to /usr/lib$suffix/qt5/bin. What else?

Please choose one of:
 a) we wrap all the executables there in /usr/bin
 b) we wrap only some of the executables there in /usr/bin (please include a 
list of which ones)
 c) we wrap some executables in /usr/bin and we symlink others to /usr/bin 
(please include a list of which ones on each group)
 d) we do nothing

If you choose any option of a to c, we require --prefix=/usr and modification to 
the buildsystem. If you choose option d, then please provide the script or at 
least very detailed instructions for distributions on how to populate 
/usr/bin.

Also, do I understand correctly that you're suggesting that multiarch 
distributions should have *both*:
	/usr/lib/qt5//bin/assistant		AND		/usr/lib64/qt5/bin/assistant
	/usr/lib/qt5//bin/linguist		AND		/usr/lib64/qt5/bin/linguist
	/usr/lib/qt5//bin/designer		AND		/usr/lib64/qt5/bin/designer

If you're not suggesting that, then are you suggesting that those applications 
should be symlinked directly to /usr/bin, instead of tool-wrapped (which 
detects multiarch)? Are there any other tools that you suggest should be 
symlinked?
-- 
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/20121031/88138713/attachment.sig>