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 namespacing.
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. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
