On Wed, Oct 31, 2012 at 08:02:20AM -0700, Thiago Macieira wrote: > On quarta-feira, 31 de outubro de 2012 12.23.27, Oswald Buddenhagen wrote: > > > 3) library versioning (i.e., adding "5" to the library name) > > > > -1 > > > > renaming is unnecessary: > > - there is no problem at all at run-time > > - the problem at build time is solved by -L flags. there is no need for > > an unversioned symlink in /usr/lib. > > renaming is a bit disruptive: > > - projects not done with qmake need adjustment/ifdefs > > - but then, they probably need adjustment anyway due to the libraries > > having been split, etc. > > Ossi: let me ask you something then: do you want our make install to manage > both /usr/lib *and* /usr/lib/qt5/lib? > no.
> My argument is that the split is necessary because we're being asked to > manage > all of this. I'm also with Ján here that trying to override the default > search > paths is troublesome. Some less sophisticated buildsystems might add > -L/usr/lib64 due to other dependencies saying that is necessary, then all of > a > sudden the application will start linking to Qt 4. > > (on OpenSUSE) $ mysql_config --libs > -L/usr/lib64 -lmysqlclient -lpthread -lz -lm -lrt -lssl -lcrypto -ldl > 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. > > the -archdatadir option as such does not hurt, but it introduces a > > backwards-incompatibility (projects which don't use it on a system which > > uses different dirs will fail to find the data). i'd prefer to postpone > > this to The Next Real Major Version ™. > > The only thing that uses DataDir is qmake, to find its mkspecs. Also, quite > clearly QLibraryInfo is about Qt itself. > yes. this includes qt translations (and qt docs, but that's relevant only for creator, pretty much). but these live in the old data path, so it's ok. > Other libraries and applications have > no business using those paths. Therefore, I argue that: > > 1) they shouldn't store their files there > 2) if they are using to read some Qt files, the only ones affected are the > mkspecs, which require quite an updated parser anyway. > ok, whatever. > > > 5) executable split between end-user applications and indirect tooling > > > [...] > > > > -2 > > > > > This proposal has met with vehement opposition and I'd like to hear why. > > > > as others pointed out, the split is arbitrary, and - given your wrapper > > - just unnecessary. > > Ok, then let's see what your proposal is: > > All of our executables are installed to /usr/lib$suffix/qt5/bin. What else? > > Please choose one of: > a) we wrap all the executables there in /usr/bin > b) we wrap only some of the executables there in /usr/bin (please include a > list of which ones) > c) we wrap some executables in /usr/bin and we symlink others to /usr/bin > (please include a list of which ones on each group) > d) we do nothing > this > If you choose any option of a to c, we require --prefix=/usr and > modification to the buildsystem. > 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. > 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. 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? 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. regards _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development