[Development] Pending decisions on co-installation

Oswald Buddenhagen oswald.buddenhagen at digia.com
Fri Nov 2 15:11:40 CET 2012


On Thu, Nov 01, 2012 at 01:12:14PM -0700, Thiago Macieira wrote:
> 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.
> 
apparently

> 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.
> 
no, we don't, because nobody would install both linugist:i386 and
linguist:amd64. this follows directly from what i said before.

> > 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-bis) archdatadir exists, but its default is inadequate
>       configure -prefix /usr -bindir %{_libdir}/qt5/bin -datadir %{_datadir}/qt5 \
>               -archdatadir %{_libdir}/qt5 -nomake examples -nomake tests
>       [same as a-original]
> 
> a-ter) archdatadir exists and its default is adequate, but we still don't 
> manage symlinks:
>       configure -prefix /usr -bindir %{_libdir}/qt5/bin \
>               -nomake examples -nomake tests
>       [same as a-orginal]
> 
> ============================
> 
> 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.
> 
> ============================
> 
> We have then four options due to having two decisions: the defaults 
> for archdatadir and datadir, and the managing of symlinks or not.
>
i want the one which is implied by defaults which do not change how
"normal" builds of qt look - that would be a-bis.

the management of symlinks is completely orthogonal to the qt
installation - these are symlinks to the wrapper, and must be part of
its installation process. anything else is fundamentally wrong due to
the 1:n relationship between the wrapper and the qt installations. if
anything at all, the qt installation could try to automatically register
its bindir with an already installed wrapper (but most probably this
should be a separate target, as the registration can touch files outside
-prefix by design).

regards



More information about the Development mailing list