[Development] Pending decisions on co-installation

[Thiago Macieira]

On quinta-feira, 1 de novembro de 2012 20.32.06, Oswald Buddenhagen wrote:
> > You're asking that they have a different 32-bit package to be installed on
> > 64- bit systems than then 32-bit package to be installed on 32-bit
> > systems. That's a policy change.
> 
> last time i looked, /usr/lib/i386-linux-gnu was already different from
> /usr/lib/x86_64-linux-gnu, so "policy change" seems a bit far-fetched.

I'm sorry, let me be more precise:

/usr/bin is the same for both installations. The distributions have already 
figured out a way of de-duplicating the binaries, if they end up in the common 
directory. I'm not sure exactly *how* it works or even if it works the same 
way for all distros, but they have clearly figured it out.

But we're not installing to the common directory. We're installing to an arch-
specific path, which the existing infrastructure may not be equipped to handle. 
So it's entirely possible we'll end up with duplication of executables.

Still, according to your suggestion -- wrap all tools -- we'll need that 
because the wrapper cannot know which tools have arch-independent uses and 
which ones are arch-dependent. That's a decision that the tool can't make and 
we'll ask downstream not to make either. Only the Qt Project can make that 
decision and -- according to your suggestion -- we will not make.

> > And I'm requesting that we stop this game of "qt sandbox root" and just do
> > it right, like every single other package: --prefix=/usr and manage our
> > stuff properly.
> 
> this doesn't quite fit the idea of the executable dispatcher. ;)

Sure it does. Did you see my email that contained the listing of the installed 
build? I guess you missed the attachment:

./bin/
./bin/assistant
./bin/designer
./bin/lconvert -> /home/thiago/qt5/lib64/qt5/bin/toolwrapper
./bin/linguist
./bin/lrelease -> /home/thiago/qt5/lib64/qt5/bin/toolwrapper
./bin/lupdate -> /home/thiago/qt5/lib64/qt5/bin/toolwrapper
./bin/pixeltool
./bin/qdbus
./bin/qdbusviewer
./bin/qglinfo
./bin/qmake -> /home/thiago/qt5/lib64/qt5/bin/toolwrapper
./bin/xmlpatterns
./bin/xmlpatternsvalidator


> the question is only whether we go the whole nine yards or stop halfway
> through. if we stop, the configure command line will be -prefix /usr
> -bindir /usr/lib/$arch/qt5/bin, which isn't exactly the pinnacle of
> beauty. but then, -archlibdir needs adjustment anyway.

Are these the three possibilities you're thinking of?

a) we don't do the symlinks in /usr/bin:
	configure -prefix %{_libdir}/qt5 -libdir %{_libdir} -docdir %{_docdir} \
		-translationsdir %{_datadir}/qt5/translations \
		-nomake examples -nomake tests
	make
	make install
	cd %{_libdir}/qt5/bin
	for f in *; do
		test "$f" = "toolwrapper" && continue
		ln -s %{_libdir}/qt5/bin/toolwrapper %{_bindir}
	done

b) we do manage /usr/bin, but archdatadir and datadir defaults are inadequate:
	configure -prefix /usr  -datadir %{_datadir}/qt5 -archdatadir \
		%{_libdir}/qt5 -nomake examples -nomake tests
	make
	make install

c) we do manage /usr/bin and the defaults are adequate:
	configure -prefix /usr -nomake examples -nomake tests
	make
	make install

I do realise that the current order of the patches leads to options a and c 
only. I need to split the patch that adds archdatadir so that option b is 
opened up and we can apply the Qml2ImportsPath patch.

-- 
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/075a9a1a/attachment.sig>