[Development] Co-installation & library naming rules

Oswald Buddenhagen oswald.buddenhagen at digia.com
Wed Oct 10 18:03:31 CEST 2012

On Sun, Sep 23, 2012 at 08:30:31PM +0200, Erik van Pienbroek wrote:
> why not solve the problem at the level where it's supposed to be
> fixed, upstream?
i disagree with your premise. ;)
the whole proposal addresses only one specific issue: conflicts between
major qt versions. like it or not, this is an issue specific to linux
distributors. which translates to some 20 people in the world who even
need to think about properly solving it.
what about different build configurations of the same version (i.e.,
your x-compiling use case)? qmake5-win32-pc-i386?
what about concurrent minor version of the same major version? qmake5.1?
by encoding the major version but nothing else in the basenames of the
artifacts, those who have more complex setups are forced to use double

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.

in the original report, i've indicated that i'd be willing to
"de-conflict" the .pc files. i'm not sure about that any more - it's
exactly the same problem, just that it concerns the configuration of a
particular tool, not what people use manually. otoh, that tool simply
cannot answer the configuration questions posed above, so it may make
sense to go for this half-assed solution (just like with the cmake
config files). that solution also happens to be sufficient for your
distribution problem, as all necessary information can be put into the
.pc files, thus making things still work even if fedora decides to use
libQtFunkyCore42.so.5.0.0 and qmake-with-ponies-5.

More information about the Development mailing list