[Development] Pending decisions on co-installation

[Thiago Macieira]

On quinta-feira, 1 de novembro de 2012 10.57.59, Oswald Buddenhagen wrote:
> > 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.

Which they do: the Qt 4 .so files are in /usr/lib64, /usr/lib. Since mainstream 
distros do that, it becomes our problem.

Do you have a suggestion for fixing this? Please be reasonable -- asking them 
to change their policies is not.

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

No, it doesn't include translations because we have 
QLibraryInfo::TranslationsPath. If anyone is finding translations by DataPath + 
"/translations", they deserve to get their code broken.

The only thing that uses DataPath are the mkspecs.

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

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

Ok, so the suggestion from you is that the distros install the wrapper however 
they like. They may wrap some tools, all tools, symlink some others, leave 
some unreachable in $PATH...

And this changes from distro to distro. Great.

You MUST provide a set of installation instructions. This is YOUR proposal, 
which we must analyse and compare to mine.

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

Right, so not only are you not providing instructions, you're also asking 
distributions to come up with new packaging rules for multiarch, requiring 
features in their buildsystems that they don't have yet?

Do you quite realise how unreasonable this sounds?

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

Clearly we should not touch anything outside -prefix.

Which is why I'm proposing we recommend -prefix=/usr and then we *do* manage 
that.

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

*sigh*

Requiring qmake in order to run cmake or pkg-config is NOT acceptable.

PLEASE provide the post-make-install script. Do you hear yourself when you say 
that our make install is insufficient? That distros need to move files around and 
create symlinks on their own because we can't be bothered to fix our 
buildsystem?

If you get the right to -2, then I'm also vetoing your rejection. We're now at 
an impasse.

Lars, we need a tie-breaker.
-- 
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/20121101/fff54086/attachment.sig>