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

> 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