On Tue, Sep 16, 2014 at 5:55 AM, Luís Pereira <luis.artur.pere...@gmail.com> wrote: > On Wed, Sep 10, 2014 at 9:59 AM, PCMan <pcman...@gmail.com> wrote: >> I totally understand your purpose, but we don't really want to provide >> co-installable binaries for both versions. It just does not make any >> sense for the users. >> Is there any real use case of installing both versions at the same time? >> Only changing the suffix won't work at all. >> You have to check every *.desktop files in every component and make >> sure the Exec key also uses the suffix. This is not a trivial task and >> can make our CMake rules more complicated. Besides, if other third >> party programs want to launch lxqt programs by command line, they >> won't be able to do it reliably since the program names can have any >> suffix that they don't know. Also we'll have different program names >> in different distros since some of them may apply the suffix, and >> others won't and this can be confusing. > > The .desktop files (and probably some scripts) are the ones that make > that approach infeasible. > Well... the distros sometimes change the names anyway. >> >> The only use of making qt4 and qt5 builds of lxqt co-installable is >> for ease of development. >> We can install both versions and test them more easily. >> However, the correct way to do this is using a different >> CMAKE_INSTALL_PREFIX, not doing the suffix hack in our CMake files. >> Just use cmake -DCMAKE_INSTALL_PREFIX=/opt/lxqt-qt4 or something, then >> you can make them co-installable immediately without any changes on >> our side. >> While I totally agree with you that it will make development easier, >> IMHO this is not the right approach. We should just use a different >> CMAKE_INSTALL_PREFIX. That's the standard way to achieve this. >> > To do that the base libraries must have distinct names. Otherwise we > will mess the ldconfig cache. > If the libraries have the same name the executable will be dynamic > linked to the first library it finds, but it might be the wrong > library. > We can have the same names and play with the LD_LIBRARY_PATH..... but > that will make the bug fixing in the Qt4 version a slower. > >>> What do you we do with the base libraries name ? liblxqt-qt5 becomes >>> liblxqt ? >>> we install to /usr/include/lxqt or /usr/include/lxqt-qt5 ? >> >> It's reasonable to make the base libraries co-installable since they >> can be used outside LXQt and other developers who use the libs might >> still use Qt4. So it's a good idea to have different library names. >> Your libqtxdg is one of the best libraries that is very useful for any >> Qt programs so having both version co-installable really helps 3rd >> party program developers a lot. >> On the contrary, I'm not sure whether liblxqt is as useful for 3rd >> party programs since only we're using that. So I don't really see a >> use case to make liblxqt-qt4 and liblxqt-qt5 co-installable. That's >> why I don't support the idea so much. > > liblxqt is probably unusable outside LXQt. But IMO it should be co > installable for the reasons I expressed earlier in this mail. > > IMO we should get: > 1) base libraries co installable > 2) everything else no co installable > > Sorry for the delays. Real life gets in the way. > > Regards, > -- > Luís Pereira
I'm OK with both solutions (with or without qt5 suffix) given it works. We have been blocked by this non-critical issue for too long. Though I'm not very fond of the approach, I'm not against that either. If someone has the time to fix all of the makefiles, I'm OK with adding the suffix. BTW, I just got a new job and is very busy this month. So I'm not able to do any coding for LXQt in this month. I'll be back later. If others (such as Luis) can fix this issue, please help do it and release LXQt 0.8. Otherwise there is no chance to get LXQt into debian. Cheers! ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk _______________________________________________ Lxde-list mailing list Lxde-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxde-list