[Development] Pending decisions on co-installation

[Oswald Buddenhagen]

On Wed, Oct 31, 2012 at 08:02:20AM -0700, Thiago Macieira wrote:
> 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?
> 
no.

> 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
> 
as pointed out in another mail, this doesn't phaze us a bit - unless
some distro thinks it's wise to override our choice and install an
unversioned symlink to /usr/lib64. for which they deserve being lynched
by their users, so it's not our problem.

> > 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.
>
yes. this includes qt translations (and qt docs, but that's relevant
only for creator, pretty much). but these live in the old data path, so
it's ok.

> 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.
> 
ok, whatever.

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

> 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.
> 
this is part of the installation (instructions) of your (to be
stand-alone ;) wrapper.

> 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
> 
yes. as these applications typically live in separate packages anyway,
there needn't to be an actual duplication if the alternatives are
intelligently managed. for example, your wrapper could support a
secondary source for executables, so if no lib32 version is found, the
lib64 version is automatically used.

On Wed, Oct 31, 2012 at 12:38:06PM -0700, Thiago Macieira wrote:
> I disagree with leaving /usr/bin unmanaged at all. I want to hear the 
> arguments on why we should not manage that on "make install".
> 
because it's outside of -prefix?

On Wed, Oct 31, 2012 at 12:44:53PM -0700, Thiago Macieira wrote:
> Here's another reason why we need to manage our libraries properly:
> cmake and pkg-config files. [...]
> 
as i said probably a week ago already, the locations of the
pkg-config/cmake files can be determined by the distros freely - they
can just have rpm & co. move them out of -prefix at packaging time. the
one thing we need to do is ensuring a consistent naming of the files.
provided we want users to be able to use the files without setting up
environment variables, we'd need to make them co-installable, indeed.
but i'm not entirely conviced we need that: we could just say that
pkg-config needs to be set up with the qmake -query output. that might
be considered an undue complication, though.

regards