[Development] Pending decisions on co-installation

[Thiago Macieira]

On quinta-feira, 1 de novembro de 2012 17.13.58, Oswald Buddenhagen wrote:
> > You MUST provide a set of installation instructions. This is YOUR
> > proposal,
> > which we must analyse and compare to mine.
> 
> my proposal is very simple: wrap everything in QT_HOST_BINS (which
> equals QT_INSTALL_BINS on desktops, but it matters for x-builds).

Ok, the proposal is that every single binary in BINDIR should be wrapped. At 
least that's an easy script to write.

> > > > 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?
> 
> one has to wonder how you arrive at these conclusions ...

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.

> > > 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.
> 
> this is a semantics game. the real prefix (the qt "sandbox" root) will be
> different anyway. just accept that the prefix of the wrapper is a
> different one, and consequently that it is a separate package.
> this wouldn't even change if the packagers use configure's path options
> in such ways that the "prefixes" actually end up intermingled.

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.

> > > 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.
> 
> i don't buy such a statement without justification.

This point is now moot. Since Lars decided on having the 5 in the lib names, 
we can have LIBDIR=/usr/lib and therefore the pkgconfig and cmake files are 
installed to the proper places. No need for further changes on our side.

> > 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
> 
> this sounds entirely reasonable to me. this is what packaging is about.

Please talk to packagers then. "Reasonable" is "make install is sufficient".

> actually, because we refuse to tailor it to their needs at the cost of
> others.

Cost of others? No one else is suffering from this. If there are people who are 
seeing negative effects from the proposed changes, please tell me, because I 
still don't see them.

Please bring those arguments to the meeting in Berlin.

-- 
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/6f3455b0/attachment.sig>