[Development] Co-installation & library naming rules

Oswald Buddenhagen oswald.buddenhagen at digia.com
Thu Oct 11 11:45:27 CEST 2012

On Wed, Oct 10, 2012 at 10:44:30AM -0700, Thiago Macieira wrote:
> On quarta-feira, 10 de outubro de 2012 18.03.31, Oswald Buddenhagen wrote:
> > which translates to some 20 people in the world who even
> > need to think about properly solving it.
> Indeed. But their output affects a lot of people, including the majority of 
> future Qt contributors,
that's not relevant, because if those 20 people do a good job, the
millions using the packages will not be bothered by this topic. i find
it more important to optimize for those who use custom builds with
path-based setups (actual contributors and ISVs).

> > what about concurrent minor version of the same major version? qmake5.1?
> Not necessary. qmake retains the necessary backwards compatibility. The newer 
> version replaces the previous with all functionality necessary.
that's a bit of wishful thinking. sometimes you need bug-for-bug
compatibility, and having the build scripts differentiate not only
between qt versions but also between component versions is an utter

> Co-installing multiple versions of the same major-version package requires 
> renaming beyond what we (or GCC) support. That's really up to distributors.
it's not up to the distributors, because they couldn't care less for
this non-usecase, as far as they are concerned. that's why they endorse
your proposal. i otoh don't see why we should disproportionately favor
one group at the cost of other groups (specifically, see lincoln's mail).

> > nope, sorry, the version-based namespacing simply does not belong into
> > upstream. it's a problem specific to FHS, and should be addressed by
> > those concerned with it.
> It belongs in Qt and people have already agreed to it. We need to fix it in Qt.
not all people have agreed on it. the linux distro centric camp (which
has a disproportionate representation in this channel) has agreed on it.
which is a very good indication that they should, indeed, have a common
standard. *their* standard. which reaches way beyond qt.

More information about the Development mailing list