[Development] Pending decisions on co-installation

[Oswald Buddenhagen]

On Thu, Nov 01, 2012 at 08:20:02AM -0700, Thiago Macieira wrote:
> On quinta-feira, 1 de novembro de 2012 10.57.59, Oswald Buddenhagen wrote:
> > 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.
> 
they have to adapt to our strict sandboxing requirement for the binaries
anyway. it's not unreasonable to expect them to make some minor
adjustments to the -dev package, too.

> > > 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.
> 
my proposal is very simple: wrap everything in QT_HOST_BINS (which
equals QT_INSTALL_BINS on desktops, but it matters for x-builds).

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

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

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

pkg-config is used within configure scripts anyway, so requiring
environment setup based on previous checks is entirely reasonable -
heck, we even manage to do that with qmake.

for cmake the situation is somewhat different.
steve is trying to ship everything which is needed to use the qt modules
with qt itself, so there is no external entity which would obtain the
correct path by calling qmake. note that this also means that x-build
target selection with the wrapper won't work, either.
also, the cmake modules are already versioned - so this isn't an
all-or-nothing deal.

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

> because we can't be bothered to fix our buildsystem?
> 
actually, because we refuse to tailor it to their needs at the cost of
others.
the cost of renaming the libraries is minor, but so is the benefit, once
one strips away all the bogus arguments - that's why i'm undecided.