Re: [Development] Co-installation library naming rules
-Original Message- From: development-bounces+jan-arve.saether=digia@qt-project.org [mailto:development-bounces+jan-arve.saether=digia@qt-project.org] On Behalf Of Simon Hausmann Sent: 18. oktober 2012 16:42 To: development@qt-project.org Cc: Thiago Macieira Subject: Re: [Development] Co-installation library naming rules On Thursday, October 11, 2012 04:11:10 PM Thiago Macieira wrote: On quinta-feira, 11 de outubro de 2012 21.16.56, Oswald Buddenhagen wrote: On Thu, Oct 11, 2012 at 11:56:44AM -0700, Thiago Macieira wrote: Considering all the changes I am proposing do NOT harm any of the people that build from sources, they *do* harm. i positively do *not* want to use qmake-qt5 just because it's the least evil for linux package users. That's the very most important change that needs to be done: renaming qmake. All the other tools could be separated elsewhere, the libs could be in different dirs. But qmake is the one tool run directly by users, the one tool that Qt Creator asks users to locate. It needs to be renamed.. If you don't want to make it the default, then at the very least we need to add the option to our configure script to force the renaming. We need to adapt our buildsystem to creating the renamed tool. This is not debatable... we simply need to do it in Qt. I don't want distribution packagers choosing different methods: I want them all to have the same solution, the one solution that will be recommended to LSB 5.0, the one solution that the helpful people in #qt, interest@ and other discussion channels will need to know. In other words, the renaming will be the de-facto default for everyone using Linux. Why the hell shouldn't it be the de jure default too? As it turns out, we may not need to rename it. Let's just take it out of /usr/bin, along with the other binaries. Let's put them into /usr/lib/qt5/libexec for example. (Heck, distros can tweak that via configure if they want to). If instead we had a proper equivalent of qset as a real program that would allow changing between different Qt versions easily, then it wouldn't matter where that qmake binary is. If it's in $HOME/dev/qt5/qtbase/bin or in /usr/lib/qt5/libexec/ - I would use qt qmake and depending on what my current Qt version is, it would call the right qmake binary. +1 It should also be possible to just use qmake (instead of qt qmake) by using aliases. (But that's just sugar on top) Jan Arve ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Thursday, October 11, 2012 04:11:10 PM Thiago Macieira wrote: On quinta-feira, 11 de outubro de 2012 21.16.56, Oswald Buddenhagen wrote: On Thu, Oct 11, 2012 at 11:56:44AM -0700, Thiago Macieira wrote: Considering all the changes I am proposing do NOT harm any of the people that build from sources, they *do* harm. i positively do *not* want to use qmake-qt5 just because it's the least evil for linux package users. That's the very most important change that needs to be done: renaming qmake. All the other tools could be separated elsewhere, the libs could be in different dirs. But qmake is the one tool run directly by users, the one tool that Qt Creator asks users to locate. It needs to be renamed.. If you don't want to make it the default, then at the very least we need to add the option to our configure script to force the renaming. We need to adapt our buildsystem to creating the renamed tool. This is not debatable... we simply need to do it in Qt. I don't want distribution packagers choosing different methods: I want them all to have the same solution, the one solution that will be recommended to LSB 5.0, the one solution that the helpful people in #qt, interest@ and other discussion channels will need to know. In other words, the renaming will be the de-facto default for everyone using Linux. Why the hell shouldn't it be the de jure default too? As it turns out, we may not need to rename it. Let's just take it out of /usr/bin, along with the other binaries. Let's put them into /usr/lib/qt5/libexec for example. (Heck, distros can tweak that via configure if they want to). If instead we had a proper equivalent of qset as a real program that would allow changing between different Qt versions easily, then it wouldn't matter where that qmake binary is. If it's in $HOME/dev/qt5/qtbase/bin or in /usr/lib/qt5/libexec/ - I would use qt qmake and depending on what my current Qt version is, it would call the right qmake binary. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On 12.10.2012, at 01:11, Thiago Macieira wrote: On quinta-feira, 11 de outubro de 2012 21.16.56, Oswald Buddenhagen wrote: On Thu, Oct 11, 2012 at 11:56:44AM -0700, Thiago Macieira wrote: Considering all the changes I am proposing do NOT harm any of the people that build from sources, they *do* harm. i positively do *not* want to use qmake-qt5 just because it's the least evil for linux package users. That's the very most important change that needs to be done: renaming qmake. All the other tools could be separated elsewhere, the libs could be in different dirs. But qmake is the one tool run directly by users, the one tool that Qt Creator asks users to locate. Especially for Qt Creator users I don't see any reason for renaming qmake. I don't see any issue with pointing it to qmake in different directories. Qt Creator doesn't care if qmake is in the path or not. That's what we do all the time with our self-compiled Qt versions too. It needs to be renamed.. If you don't want to make it the default, then at the very least we need to add the option to our configure script to force the renaming. We need to adapt our buildsystem to creating the renamed tool. This is not debatable... we simply need to do it in Qt. I don't want distribution packagers choosing different methods: I want them all to have the same solution, the one solution that will be recommended to LSB 5.0, the one solution that the helpful people in #qt, interest@ and other discussion channels will need to know. In other words, the renaming will be the de-facto default for everyone using Linux. Why the hell shouldn't it be the de jure default too? Other than that it requires work on your part, Ossi. oh, i'm not worried about the work. saying no is easy. the patches would of course be written by those who want the changes. ;) I'm willing to put in the effort to make it happen. I've already created one patch going in that direction[1]. But you're the maintainer of the buildsystem and your objections so far would indicate a -2 on your part. [1] https://codereview.qt-project.org/#change,35495 -- Thiago Macieira - thiago.macieira (AT) intel.comhttp://intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.orgmailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
Thiago Macieira schreef op do 11-10-2012 om 16:11 [-0700]: On quinta-feira, 11 de outubro de 2012 21.16.56, Oswald Buddenhagen wrote: oh, i'm not worried about the work. saying no is easy. the patches would of course be written by those who want the changes. ;) I'm willing to put in the effort to make it happen. I've already created one patch going in that direction[1]. But you're the maintainer of the buildsystem and your objections so far would indicate a -2 on your part. [1] https://codereview.qt-project.org/#change,35495 Here's another one which I already proposed some time ago (to make linking against static Qt libraries work when ./configure -qtlibinfix is used) but it was rejected: https://codereview.qt-project.org/#change,34981 Kind regards, Erik van Pienbroek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Thursday, October 11, 2012 11:45:27 AM Oswald Buddenhagen wrote: [...] 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. Yes, in an ideal world the FHS would solve this. But unfortunately the reality of the matter is that this just isn't going to be solved there. That's probably also why other middleware projects have decided to solve the issue on their end years ago (gstreamer, dbus, glib, gtk and many more), because at the end of the day what _really_ matters are the users of Qt. Without the users of Qt we're not relevant. It is _our_ goal that Qt 5 is a no-brainer to install and use, on as many developer workstations as possible. In the process of that we should make life easier for middlemen like the Linux distro packagers, and with this proposal also unify the naming of Qt 5 libraries/binaries throughout the different distros (because we solve the problem in a central place). Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On quinta-feira, 11 de outubro de 2012 11.45.27, Oswald Buddenhagen wrote: 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). You're assuming that they will all do the *same* good job. If they don't, then we'll have different solutions in different distributions and the pain of supporting the users will fall on us, not on them. Who do you think staffs #qt on Freenode? The other thing is, we still need to rename the libraries. Otherwise, we can't install both sets of *.so files to /usr/lib. If we do that, we've solved the majority of the problem anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Thu, Oct 11, 2012 at 02:59:03PM +0200, Simon Hausmann wrote: On Thursday, October 11, 2012 11:45:27 AM Oswald Buddenhagen wrote: 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. Yes, in an ideal world the FHS would solve this. But unfortunately the reality of the matter is that this just isn't going to be solved there. everyone knows that the FHS is not going to move. i'm arguing that those who are dealing with it should build upon it, which is the distributors. On Thu, Oct 11, 2012 at 08:06:47AM -0700, Thiago Macieira wrote: On quinta-feira, 11 de outubro de 2012 11.45.27, Oswald Buddenhagen wrote: 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. You're assuming that they will all do the *same* good job. that's a rather reasonable assumption. that's why they are here. i don't see why they should be able to compel the qt project to do something they apparently all want, but be incapable of agreeing on a standard under the qt project's umbrella and implementing it only in their own repos. The other thing is, we still need to rename the libraries. Otherwise, we can't install both sets of *.so files to /usr/lib. that's simply not a relevant concern. production libraries can be co-installed just fine. and development libraries can live in their respective subfolders and be found via the respective -L options (which come out of pkg-config - which is why i'm _considering_ making the .pc files co-installable out of the box). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Thu, Oct 11, 2012 at 11:46 AM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: On Thu, Oct 11, 2012 at 02:59:03PM +0200, Simon Hausmann wrote: On Thursday, October 11, 2012 11:45:27 AM Oswald Buddenhagen wrote: 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. Yes, in an ideal world the FHS would solve this. But unfortunately the reality of the matter is that this just isn't going to be solved there. everyone knows that the FHS is not going to move. i'm arguing that those who are dealing with it should build upon it, which is the distributors. On Thu, Oct 11, 2012 at 08:06:47AM -0700, Thiago Macieira wrote: On quinta-feira, 11 de outubro de 2012 11.45.27, Oswald Buddenhagen wrote: 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. You're assuming that they will all do the *same* good job. that's a rather reasonable assumption. that's why they are here. i don't see why they should be able to compel the qt project to do something they apparently all want, but be incapable of agreeing on a standard under the qt project's umbrella and implementing it only in their own repos. Why would forcing multiple implementations in different repos be better than agreeing upon and implementing this in the upstream repo? If there is no cooperation then yes distro packagers need to come up with their own solutions, and can work to coordinate this across distros. If there is a general agreement that this is needed then it would seem that doing this in the context of the Qt project is the ideal solution. This would also reduce the amount of work required as there is already an agreed upon place to collaborate (the Qt project), and as we all get our source from the Qt project there is minimal opportunity for solutions to diverge. Marcus ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On quinta-feira, 11 de outubro de 2012 17.46.11, Oswald Buddenhagen wrote: The other thing is, we still need to rename the libraries. Otherwise, we can't install both sets of *.so files to /usr/lib. that's simply not a relevant concern. production libraries can be co-installed just fine. and development libraries can live in their respective subfolders and be found via the respective -L options (which come out of pkg-config - which is why i'm considering making the .pc files co-installable out of the box). I'd simply version the libraries. We already do that on Windows too, for example. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On quinta-feira, 11 de outubro de 2012 12.00.41, Marcus D. Hanwell wrote: If there is a general agreement that this is needed then it would seem that doing this in the context of the Qt project is the ideal solution. This would also reduce the amount of work required as there is already an agreed upon place to collaborate (the Qt project), and as we all get our source from the Qt project there is minimal opportunity for solutions to diverge. Agreed. Think about this: There are a certain number of people who build Qt from sources. Those are usually the Qt developers, the embedded device developers, the packagers and a handful of KDE developers. The vast majority will get it pre-built. Considering all the changes I am proposing do NOT harm any of the people that build from sources, why should we NOT do them? Other than that it requires work on your part, Ossi. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Thu, Oct 11, 2012 at 11:54:28AM -0700, Thiago Macieira wrote: I'd simply version the libraries. yes. me too. i wouldn't rename them, though. ;) We already do that on Windows too, for example. only because windows has no built-in support for versioning dlls. and fwiw, what qmake does is an utter hack which causes trouble on a regular basis. your whole argument is built on the premise that the system-provided versioning is broken enough that we should ignore it and just claim that different major versions are different libraries alltogether. i disagree with this premise. and i dislike what consequences it has for everything else which is not a library, and the effect it has on *me*, a qt developer. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Thu, Oct 11, 2012 at 11:56:44AM -0700, Thiago Macieira wrote: Considering all the changes I am proposing do NOT harm any of the people that build from sources, they *do* harm. i positively do *not* want to use qmake-qt5 just because it's the least evil for linux package users. Other than that it requires work on your part, Ossi. oh, i'm not worried about the work. saying no is easy. the patches would of course be written by those who want the changes. ;) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On quinta-feira, 11 de outubro de 2012 21.16.56, Oswald Buddenhagen wrote: On Thu, Oct 11, 2012 at 11:56:44AM -0700, Thiago Macieira wrote: Considering all the changes I am proposing do NOT harm any of the people that build from sources, they *do* harm. i positively do *not* want to use qmake-qt5 just because it's the least evil for linux package users. That's the very most important change that needs to be done: renaming qmake. All the other tools could be separated elsewhere, the libs could be in different dirs. But qmake is the one tool run directly by users, the one tool that Qt Creator asks users to locate. It needs to be renamed.. If you don't want to make it the default, then at the very least we need to add the option to our configure script to force the renaming. We need to adapt our buildsystem to creating the renamed tool. This is not debatable... we simply need to do it in Qt. I don't want distribution packagers choosing different methods: I want them all to have the same solution, the one solution that will be recommended to LSB 5.0, the one solution that the helpful people in #qt, interest@ and other discussion channels will need to know. In other words, the renaming will be the de-facto default for everyone using Linux. Why the hell shouldn't it be the de jure default too? Other than that it requires work on your part, Ossi. oh, i'm not worried about the work. saying no is easy. the patches would of course be written by those who want the changes. ;) I'm willing to put in the effort to make it happen. I've already created one patch going in that direction[1]. But you're the maintainer of the buildsystem and your objections so far would indicate a -2 on your part. [1] https://codereview.qt-project.org/#change,35495 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On quinta-feira, 11 de outubro de 2012 21.09.24, Oswald Buddenhagen wrote: On Thu, Oct 11, 2012 at 11:54:28AM -0700, Thiago Macieira wrote: I'd simply version the libraries. yes. me too. i wouldn't rename them, though. ;) We already do that on Windows too, for example. only because windows has no built-in support for versioning dlls. and fwiw, what qmake does is an utter hack which causes trouble on a regular basis. Kill two birds with one stone: remove the hacks by inserting the 5 into the actual name. your whole argument is built on the premise that the system-provided versioning is broken enough that we should ignore it and just claim that different major versions are different libraries alltogether. It's not broken. What I'm saying is that the rules we've followed so far are insufficient. They need to be amended for source-incompatible and co-installable libraries. i disagree with this premise. and i dislike what consequences it has for everything else which is not a library, and the effect it has on *me*, a qt developer. The only tools that need renaming are the tools that are run by users but are tied to a specific library version. That's basically qmake. If we had a generic build tool that worked with multiple Qt versions (like cmake), we wouldn't need to do it. Since our tool hardcodes Qt specifics and is not backwards compatible with older versions, we need to. That was our decision. Most of the other tools can go unrenamed: they'll either be in libexec because they're not run directly by the user, or they're end-user applications that retain compatibility (creator, qdbus, assistant, linguist and its tools, etc.). The only exceptions are tools that load plugins, like designer, and even then, one could argue that the same .ui should work with either uic. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On 12/10/12 09:18, Thiago Macieira wrote: The only tools that need renaming are the tools that are run by users but are tied to a specific library version. That's basically qmake. If we had a generic build tool that worked with multiple Qt versions (like cmake), we wouldn't need to do it. Since our tool hardcodes Qt specifics and is not backwards compatible with older versions, we need to. That was our decision. So why the arbitrary distinction of major version then? I can trivially produce source-incompatible builds of Qt from the source sources. Are we really going to guarantee that you'd never need more than one minor version of a specific major Qt installed at the same time? I don't see this as any different to a tool like the compiler. What I run in 99% of cases is gcc and the distro has decided which version that should be. For installing multiple versions, I can use the complete name (arch-platform-etc-version-gcc) or set my PATH to where that version's actual binaries are and continue to use gcc. -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On sexta-feira, 12 de outubro de 2012 10.01.03, Lincoln Ramsay wrote: On 12/10/12 09:18, Thiago Macieira wrote: The only tools that need renaming are the tools that are run by users but are tied to a specific library version. That's basically qmake. If we had a generic build tool that worked with multiple Qt versions (like cmake), we wouldn't need to do it. Since our tool hardcodes Qt specifics and is not backwards compatible with older versions, we need to. That was our decision. So why the arbitrary distinction of major version then? It's not arbitrary. See the rationale and the other emails. But it boils down to the fact that we're breaking source compatibility and it is a major release, with major changes, changes we don't usually do in other releases. I can trivially produce source-incompatible builds of Qt from the source sources. I don't see how that's relevant. Are we really going to guarantee that you'd never need more than one minor version of a specific major Qt installed at the same time? Yes... that's the policy, at least per architecture. Whether we succeed or not, that's different. It's also what everyone else does. I don't see why we should be different. I don't see this as any different to a tool like the compiler. Nor do I, for a user tool that maintains compatibility. qmake does not fit that description, so it's out. What I run in 99% of cases is gcc and the distro has decided which version that should be. For installing multiple versions, I can use the complete name (arch-platform-etc-version-gcc) or set my PATH to where that version's actual binaries are and continue to use gcc. Sure, and that's fine if we wanted to have multiple qmake from the same major version installed, including for cross-compilations. What I'm asking for is to include the Qt major version as part of the differentiation, since it really is a change that people want to make. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On quarta-feira, 10 de outubro de 2012 18.03.31, Oswald Buddenhagen wrote: 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. Indeed. But their output affects a lot of people, including the majority of future Qt contributors, which have traditionally come from the Linux background. We need to provide a correct experience for those. what about different build configurations of the same version (i.e., your x-compiling use case)? qmake5-win32-pc-i386? Good point. Following GCC's lead, we could provide an option to have the executables include the arch name. But that should not be the default in non- cross-compilation builds. 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. Co-installing multiple versions of the same major-version package requires renaming beyond what we (or GCC) support. That's really up to distributors. 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. It belongs in Qt and people have already agreed to it. We need to fix it in Qt. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On 27 September 2012 06:01, Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote: IIRC, in Debian with Qt3 and Qt4 we did have both libs installed without problems. With respect the other stuff: - qmake, moc et al.: we used divertions (an apt facility) to let the user choose which one to use on compiling stuff. Binaries were renamed upon packaging to qmake-qt3/qmake-qt4 and a simlink points to one of them (thanks to the aforementioned divertions system). - Headers: I *think* thet could be installed at the same time. What was done to make it happen is a detail I don't know/remember, as I wasn part of the packaging team and we already removed qt3 from the archive. Those are good points. Co-installation requires worrying about more than just libraries. For example on Arch Linux I have both python 2.7 and 3.2 installed, because they are incompatible, and some packages require one or the other. So there are lots of links: lrwxrwxrwx 1 root root 7 Aug 20 14:48 /usr/bin/python - python2 lrwxrwxrwx 1 root root 9 Apr 24 02:02 /usr/bin/python2 - python2.7 -rwxr-xr-x 1 root root 6248 Apr 24 02:02 /usr/bin/python2.7 -rwxr-xr-x 1 root root 1618 Apr 24 02:02 /usr/bin/python2.7-config lrwxrwxrwx 1 root root16 Apr 24 02:02 /usr/bin/python2-config - python2.7-config lrwxrwxrwx 1 root root55 Jul 26 19:34 /usr/bin/python2-pykdeuic4 - /usr/lib/python2.7/site-packages/PyQt4/uic/pykdeuic4.py -rwxr-xr-x 1 root root94 Jul 17 19:55 /usr/bin/python2-pyuic4 -rwxr-xr-x 3 root root 10408 Apr 24 01:27 /usr/bin/python3 -rwxr-xr-x 3 root root 10408 Apr 24 01:27 /usr/bin/python3.2 lrwxrwxrwx 1 root root18 Apr 24 01:27 /usr/bin/python3.2-config - python3.2mu-config -rwxr-xr-x 3 root root 10408 Apr 24 01:27 /usr/bin/python3.2mu -rwxr-xr-x 1 root root 1821 Apr 24 01:27 /usr/bin/python3.2mu-config lrwxrwxrwx 1 root root16 Apr 24 01:27 /usr/bin/python3-config - python3.2-config -rwxr-xr-x 1 root root 1193 Aug 13 23:19 /usr/bin/python3-mako-render lrwxrwxrwx 1 root root14 Apr 24 01:27 /usr/bin/python-config - python3-config whereas for the libs, there is just /usr/lib/python2.7/ and /usr/lib/python3.2/, and includes are in /usr/include/python2.7/ and /usr/include/python3.2mu/ . Maybe we need to also rename the qt binaries for which the version matters? especially qmake. Why should the distros have to rename it themselves? If qmake5 becomes the standard name, they won't have to rename this or future versions. The alternative would be to install all the binaries in their own directory somewhere and make links to them from /usr/bin, but packagers probably already know about the -bindir option to configure; and each distro has its own way of making/updating the alternatives links. Likewise there could be named include dirs like /usr/include/qt5/QtCore or something like that. (It cannot be /usr/include/Qt5Core because of the habit of doing #include QtCore/ClassName .) Config has -headerdir but maybe the default should be version-specific. I'm way in favor of finally getting rid of the default prefix like /usr/local/Trolltech or /usr/local/Qt-something. I always thought that was ridiculous, not at all what anyone wants, and didn't realize for a long time what could be the reason for it, other than hubris, or a desire to replicate the Windows situation on Linux (c:\progra~1\MyIllustriousCompany\WhizBangProduct\binary.exe). It's unfortunate that people developing embedded systems often don't follow the FHS, and having defaults like that just helps to reinforce their bad habits. It could at least have defaulted to /opt/QtX for many years already. Defaulting to a more standard-looking installation in /usr/local/bin, /usr/local/lib, /usr/local/include, /usr/local/share/qt5/examples, etc. while still permitting co-installation will really be the best I think. Packagers maybe would only have to override -prefix to /usr. But how to handle co-installation of the binaries is still a good question. Probably the ones that need to go in /usr/bin need to have version suffixes? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Friday, September 21, 2012 16:47:11 Thiago Macieira wrote: This is long, so I'll give you my recommendation first. If you agree with me, you don't have to read the rest. If you disagree, you have to read my arguments. It seems like the this thread and the 'Qt 5 file hierarchy' are really part of the same proposal? It also seems like the proposal is updated a bit (eg for Mac). Can you post a combined update if so, so that we can ask distros what they think? We should find out if the proposal is 'good' to downstreams so that we can start moving on it. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ** Qt Developer Conference: http://qtconference.kdab.com/ ** signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
23.09.2012, 18:06, Thiago Macieira thiago.macie...@intel.com: Because there is only one prefix for distributions: /usr. They do not like installing elsewhere. E.g. Mandriva istalls Qt 4 into /usr/lib/qt4 prefix, and Qt 3 to /usr/lib/qt3 -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On sexta-feira, 28 de setembro de 2012 13.07.16, Stephen Kelly wrote: On Friday, September 21, 2012 16:47:11 Thiago Macieira wrote: This is long, so I'll give you my recommendation first. If you agree with me, you don't have to read the rest. If you disagree, you have to read my arguments. It seems like the this thread and the 'Qt 5 file hierarchy' are really part of the same proposal? It also seems like the proposal is updated a bit (eg for Mac). Can you post a combined update if so, so that we can ask distros what they think? We should find out if the proposal is 'good' to downstreams so that we can start moving on it. I've already contacted several downstreams: Sune for Debian, Will for OpenSUSE, Raphael for FreeBSD; the Fedora people were the originators of the bug report and have posted here. All have given their +1 to the proposal. All the Linux distros said that they will apply fixes to our build if we don't do it. Raphael, on the other hand, says that it doesn't matter for him, but it doesn't hinder either and he thinks it's cleaner this way. Sune also said that he would rather we *keep* the number at the end of the soname. As to whether we should reset to 1 or keep it at 5, Lars says he would rather we keep at 5, so no one gets ideas about making a binary-incompatible Qt 5 release. The only pending question is whether it should be libQt5Core or libQtCore5. To avoid libQtQuick5 (for Qt Quick 2) and libQtV85, I'd rather put the number next to Qt. I'll post an updated text summarising the *decision*. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Friday, September 28, 2012 13:25:42 Thiago Macieira wrote: I've already contacted several downstreams: Sune for Debian, Will for OpenSUSE, Raphael for FreeBSD; the Fedora people were the originators of the bug report and have posted here. All have given their +1 to the proposal. Thanks for doing that. I'm very surprised that they didn't email here about it and join the *discussion*. This should involve more than a +1 imo but an actual discussion. Sune also said that he would rather we *keep* the number at the end of the soname. As to whether we should reset to 1 or keep it at 5, Lars says he would rather we keep at 5, so no one gets ideas about making a binary-incompatible Qt 5 release. The only pending question is whether it should be libQt5Core or libQtCore5. To avoid libQtQuick5 (for Qt Quick 2) and libQtV85, I'd rather put the number next to Qt. That still leaves us with Qt53D. But I prefer that too as it's consistent with the cmake files. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ** Qt Developer Conference: http://qtconference.kdab.com/ ** signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
Stephen Kelly wrote: On Friday, September 28, 2012 13:25:42 Thiago Macieira wrote: I've already contacted several downstreams: Sune for Debian, Will for OpenSUSE, Raphael for FreeBSD; the Fedora people were the originators of the bug report and have posted here. All have given their +1 to the proposal. Thanks for doing that. I'm very surprised that they didn't email here about it and join the *discussion*. This should involve more than a +1 imo but an actual discussion. (With my fedora packager hat on), I intended to chime in and voice my support for the proposal sooner or later, so let me do so now. +1 seems I'd misinterpretted thiago's initial comment If you agree with me, you don't have to ... sorry 'bout that. -- rex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Fri 28 Sep 2012 09:06:43 Sune Vuorela escribió: [snip] I don't have any opinion on if we want to make it libQt5Stuff or libQtStuff5. IMVHO, libQt5Stuff seems cleaner. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
IIRC, in Debian with Qt3 and Qt4 we did have both libs installed without problems. With respect the other stuff: - qmake, moc et al.: we used divertions (an apt facility) to let the user choose which one to use on compiling stuff. Binaries were renamed upon packaging to qmake-qt3/qmake-qt4 and a simlink points to one of them (thanks to the aforementioned divertions system). - Headers: I *think* thet could be installed at the same time. What was done to make it happen is a detail I don't know/remember, as I wasn part of the packaging team and we already removed qt3 from the archive. - Versioning: yes, we do libqt4-dev (= 4.0) for qt4 stuff. I pinged Sune and Modestas to this topic, let's see if they are available. Kinds regards, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On 23 Sep 2012, at 20:30, Erik van Pienbroek e...@vanpienbroek.nl wrote: Thiago Macieira schreef op vr 21-09-2012 om 16:47 [+0200]: Include the major version number (5) in all library base names Hi, As the person who filed the mentioned QT-BUG in the first place I would like to let you know that I'm +1 to the proposal from Thiago. For the people who don't know me yet: I'm a member of the Fedora MinGW group and we provide cross-compiled binaries of Qt for the win32 and win64 targets so users can easily cross-compile their software on a Linux host and run them on Windows (or Wine). On IRC I've been discussing this subject with Kevin Kofler (Fedora KDE group) and he also +1's the proposal from Thiago Some days ago I started on packaging the entire Qt5 stack and stumbled across the fact that by default Qt4 and Qt5 can't be installed in the same prefix as there are various file name conflicts. Therefore I had to do some additional patching (like https://codereview.qt-project.org/34981 ) and manual renames to make it possible to co-install Qt4 and Qt5. The resulting packages can be found at https://bugzilla.redhat.com/showdependencytree.cgi?id=3D858058 The reason why we want to be able to co-install Qt4 and Qt5 is because all packages in Fedora are expected to follow the FHS as close as possible and the packaging rules state that no packages are allowed to conflict with each other. - unversioned applications, like assistant, linguist, qdbus, qdbusviewer Wouldn't that also conflict this rule? Or are these expected to be in its own package separate from the versioned parts of Qt? A suggestion was made in this thread that distro's should use separate prefixes to install Qt4 and Qt5. This will be a no-go as in that situation you will force all users of Qt4 or Qt5 to apply distribution-specific hacks to get their Qt-using application built. Examples of these hacks are: For qmake: - Users having to manually call $some_random_prefix/bin/qmake to select either Qt4 or Qt5 instead of having the qmake binary available in their default path For pkg-config: - Manually setting PKG_CONFIG_PATH to point to the pkg-config folder where either the Qt4 or Qt5 pkg-config files are stored As mentioned earlier in this thread the gtk folks have been using versioned library names for a very long time already and due to this the introduction of gtk3 itself was quite painless (just speaking about gtk3 here, not gnome3). All gtk-using packages are supposed to use pkg-config to detect the compiler flags for gtk. The gtk2 library has been providing a pkg-config file named 'gtk+-2.0.pc' and the gtk3 library is providing a pkg-config file named' gtk+-3.0.pc'. As these names don't conflict all gtk2-using packages rebuilt fine even when gtk3 is installed. Packages which want to use gtk3 can indicate so by using pkg-config to check for 'gtk+-3.0'. In my opinion the Qt project should make it possible to co-install Qt4 and Qt5 in the same prefix. If the Qt project refuses to do so then this will result in distributions applying random patches to get Qt5 working correctly on their distribution. This will lead to more distribution-specific hacks and will make it more hard for you guys to diagnose and resolve bugs (as you're not aware of distribution-specific patches). Now various distributions could start a collaboration to come to uniform packaging guidelines for the Qt package (naming of qmake, installation location, etc..) but why not solve the problem at the level where it's supposed to be fixed, upstream? I don't think it's fair to move the problem to the distributions. If the library name stays as is you're forcing a lot of additional work on us package maintainers while it can be resolved quite easily and now is the perfect time to do so (right before the release of a major new version of Qt) Kind regards, Erik van Pienbroek Fedora MinGW SIG ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Senior Software Engineer Digia Germany GmbH Rudower Chaussee 13, 12489 D-Berlin Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B, Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Tel: +49 30 63 92 32 55 Digia Germany is a group company of Digia Plc, Valimotie 21, FI-00380 Helsinki Finland Visit us at: www.digia.com -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the
Re: [Development] Co-installation library naming rules
On segunda-feira, 24 de setembro de 2012 08.52.42, Ziller Eike wrote: The reason why we want to be able to co-install Qt4 and Qt5 is because all packages in Fedora are expected to follow the FHS as close as possible and the packaging rules state that no packages are allowed to conflict with each other. - unversioned applications, like assistant, linguist, qdbus, qdbusviewer Wouldn't that also conflict this rule? Or are these expected to be in its own package separate from the versioned parts of Qt? Packagers are expected to split them into separate packages and allow installing the Qt 4 or Qt 5 versions (probably the latest, the 5 one). Assistant, Linguist, qdbus, qdbusviewer are simple tools that do not depend on a specific Qt version. They are capable of reading old files and saving them back, or don't operate at all on files. In fact, Designer could be in this category too, if we don't care about Qt 3 compatibility anymore. When we had an incompatible change for Assistant, we released the previous version as a separate tool for those who needed it (assistant-adp). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Friday, September 21, 2012 16:47:11 Thiago Macieira wrote: In particular, note that it's also possible to load two different major versions of a given library into memory, as the dynamic linker only cares about the full soname. More often than not, that's a bad idea. Note: does not apply to Qt Quick 2, since the version number is already part of the base library name. I don't think QtQuick2 is a good example. The library is called libQtQuick.so, and the '2' refers to the QML-based-API version, not the SONAME and not the Qt major version. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ** Qt Developer Conference: http://qtconference.kdab.com/ ** signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On segunda-feira, 24 de setembro de 2012 11.30.47, Stephen Kelly wrote: On Sunday, September 23, 2012 18:46:21 Thiago Macieira wrote: Probably. But we've been saying for 7 years that pkg-config is the official way of finding Qt. CMake's use of qmake is non-standard. CMake uses qmake for Qt 4. Not for Qt 5, which is what we're talking about here, so it's still irrelevant. I was talking about Qt 4. When the discussion came some 5 years ago when we were doing the CMake scripts for finding Qt 4 in KDE, the Qt devs made it clear that pkg-config is the official and recommended way of finding Qt. Yet CMake does not use the official way, ostensibly because it doesn't work on Windows. For Qt 5, we can say that cmake is using an officially-supported method, which are the files that Qt itself installs. I'm sure they're all on the kde-packager mailing list though, so you might even be able to reach them all in one go. That's a private list, so you'd have to ask them to reply/discuss here. Then that's off. That's a very bad attitude to have. [...] You need to reach out if you want to re-write the book. I am reaching out, but I don't want to subscribe to an unrelated mailing list to discuss Qt, especially not an open one. This discussion belongs here. The only reason for thinking of the releasing mailing list was that I expected packagers to be there in the first place. I'll happily post a call for discussion where it needs to be and contact some of the people I know directly, but the discussion remains here. If they want to package Qt, they come to us. I've called for packagers to join this list and/or the releasing mailing list more than once. These lists are too noisy for anyone who is not developing Qt itself. I'd really prefer Qt project to be known for reaching out instead of being known for lots of talk on development@, not reaching out ever, and expecting everyone to come here. That is just a very non-collaborative attitude. I'll also send the proposal email and summarise the discussion back into the ML. But people who choose to do that through me must understand that, intentionally or not, their responses and concerns will be brought to the ML under my own filter. And this ML makes the final decision. It's really in their best interest to be here. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On segunda-feira, 24 de setembro de 2012 11.33.40, Stephen Kelly wrote: On Friday, September 21, 2012 16:47:11 Thiago Macieira wrote: In particular, note that it's also possible to load two different major versions of a given library into memory, as the dynamic linker only cares about the full soname. More often than not, that's a bad idea. Note: does not apply to Qt Quick 2, since the version number is already part of the base library name. I don't think QtQuick2 is a good example. The library is called libQtQuick.so, and the '2' refers to the QML-based-API version, not the SONAME and not the Qt major version. Right, my bad. The number 2 should be in the library name, since it refers to the QML-based API version. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Friday, September 21, 2012 18:16:48 Thiago Macieira wrote: find_package(QtCore VERSION 5) or find_package(QtCore VERSION 6) This is the right way of doing it, I agree up to here. provided that the VERSION is mandatory. But I don't agree with this. Anyway, I think the names of the cmake files are mostly orthogonal. You're talking about distros packages, but cmake find_package isn't what they use anyway, so we can drop this part. Buildsystems based on pkgconfig will often have a requirement of the form: QtCore = 4.6 QtGui = 4.6 or even simply: QtCore QtGui It is also possible to specify QtGui 5.0. Any distro where that is needed, but not present is a bug in the distro. This is not a permanent solution nor does it work now. There are three problems it doesn't solve: *Currently*, the packages and dependencies are listed like I listed. We cannot require that everyone replace everything now. Won't work. In transition times, distros either have to be more exact (add 5.0) or change the name entirely (Qt5Core - Qt6Core). Saying it 'won't work' is wrong. They have to do one or the other or their packages will be completely broken. Further, it won't work for QtGui 6.0 since that would select either 4 or 5. People would have to write QtGui = 4.6 QtGui 6.0, but as I said, reality is different. QtGui = 5.0 QtGui 6.0, you mean. In reality, they have to do it, and they will. And it doesn't solve the co-installation problem. We need both 4 and 5 to install at the same time. Why? If distros decide they want that, then they can put each in a different prefix. Why is that for us to do? Those requirements do match the Qt 5 libraries: $ pkg-config --libs QtCore \= 4.6 QtGui \= 4.6 -L/home/thiago/obj/qt/qt5/qtbase/lib -lQtCore -lQtGui $ pkg-config --libs QtCore \= 4.6 QtCore \ 5.0 Requested 'QtCore 5.0' but version of Qtcore is 5.0.0 Whether that is correct or not is unknown to pkg-config. But it is known to the user of pkg-config. Who didn't think this far ahead. If they didn't have enough foresight this time, then they will next time. now: -QtCore = 4.6 +QtCore = 4.6 QtCore 5.0 Later: -QtCore = 4.6 QtCore 5.0 +QtCore = 5.0 QtCore 6.0 Even later: -QtCore = 5.6 QtCore 6.0 +QtCore = 6.0 QtCore 7.0 It seems like it would be nice for pkg-config files to be able to contain a maximum version number for some start-number. Is that possible? Sorry, what? I didn't understand. I was thinking that the pkg-config file itself could know the maximum version it can provide, given some starting point. Ie, a pkg-config file for Qt 5 would throw an error or not consider the package 'found' if it found Qt 6. I don't know enough about pkg-config to know if that's possible. Even if it is, it would just be 'nice' anyway, not 'needed'. The fact that our pkg-config files have the same name also impacts the co- installability of Qt 4 and Qt 5, and a little more: Linux distributions *will* carry Qt 4 for a number of years to come (they still have Qt 3). Evidence that they can manage this stuff on their own. Therefore, they must be able to at least have both sets of packages in their repositories. The problem comes when their buildsystems make reference to pkg- config files, such as in RPM-based distros: BuildRequires: pkgconfig(QtCore) I don't know anything about RPM, but I would be surprised if they can't specify versions there. If they can't, then that's a global bug for them, not a local one for us. They can. But we can't require all distros to patch all their .spec files to say 5.0 and = 5.0 in other places. Sure we can. It's completely reasonable. We could try and this could be done for most distros, but it wouldn't solve the problem of source packages by third parties. What third parties? Why do you think it's our problem to solve and not theirs? I don't think it's their problem to solve. I think that this is a correct change to do. They won't see it as their problem because the GTK camp has already solved this problem for years. From their point of view, they'll see us as the ones breaking the rules they already have in place. And if we refuse to act, they might opt for a path of least resistance and rename our files, which in the end hurts us more than it hurts them. We only 'refuse to act' if distros are already asking us to implement your proposal and we say no for the sake of laziness. That's not what's happening here though. Currently, it's not distros proposing this. A credible proposal would have to have input and buy-in from debian/suse/redhat/ubuntu packagers. Otherwise we'd just be changing things for the sake of it and claiming it's for their benefit. Have you reached out to them already? Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group
Re: [Development] Co-installation library naming rules
On domingo, 23 de setembro de 2012 13.10.32, Stephen Kelly wrote: In transition times, distros either have to be more exact (add 5.0) or change the name entirely (Qt5Core - Qt6Core). We do not want them to rename. That would be bad for everyone involved. So they need to replace the requirement in all of their control files. And all the third parties need to do it in their non-qmake and non-cmake requirement files too. Granted, there aren't many. Saying it 'won't work' is wrong. They have to do one or the other or their packages will be completely broken. That's what I'm trying to do: avoid breaking them. And it doesn't solve the co-installation problem. We need both 4 and 5 to install at the same time. Why? If distros decide they want that, then they can put each in a different prefix. Why is that for us to do? Because there is only one prefix for distributions: /usr. They do not like installing elsewhere. We're not going to change 20 years of practice with our 5.0 release. So each one will do different hacks to support their systems and policies. And LSB 5 will also have an optional module that is separate, opt-in, instead of the default. How about instead we just align with everyone else's practices? It seems like it would be nice for pkg-config files to be able to contain a maximum version number for some start-number. Is that possible? Sorry, what? I didn't understand. I was thinking that the pkg-config file itself could know the maximum version it can provide, given some starting point. Ie, a pkg-config file for Qt 5 would throw an error or not consider the package 'found' if it found Qt 6. I don't know enough about pkg-config to know if that's possible. Even if it is, it would just be 'nice' anyway, not 'needed'. It still does not make sense. How would QtCore.pc version 4.8.3 know anything about QtCore.pc 5? You must be thinking of a FindQt4 tool like cmake's, which uses pkg-config to find Qt 4. In that case, yeah, it can consider that Qt 5 is not Qt 4, and it isn't. But a generic pkgconfig call cannot do that because the user may have meant Qt 5. It can't consider Qt 5 not present, unless we stop installing a QtCore.pc file -- and that's what I'm calling for. The fact that our pkg-config files have the same name also impacts the co- installability of Qt 4 and Qt 5, and a little more: Linux distributions *will* carry Qt 4 for a number of years to come (they still have Qt 3). Evidence that they can manage this stuff on their own. Qt 3 did not have pkgconfig files and our library had a different name then. The one program that clashed (qmake) is still a constant source of problems for us. Do we really want to repeat the issue, multiplying it over some more files? We could try and this could be done for most distros, but it wouldn't solve the problem of source packages by third parties. What third parties? The ones linking to Qt but not using qmake or cmake. Why do you think it's our problem to solve and not theirs? I don't think it's their problem to solve. I think that this is a correct change to do. They won't see it as their problem because the GTK camp has already solved this problem for years. From their point of view, they'll see us as the ones breaking the rules they already have in place. And if we refuse to act, they might opt for a path of least resistance and rename our files, which in the end hurts us more than it hurts them. We only 'refuse to act' if distros are already asking us to implement your proposal and we say no for the sake of laziness. That's not what's happening here though. That's exactly what's happening. I'm bringing the proposal to the table and you're starting to resist it. Currently, it's not distros proposing this. Yes it is. Did you think I came up with this on my own? A credible proposal would have to have input and buy-in from debian/suse/redhat/ubuntu packagers. Otherwise we'd just be changing things for the sake of it and claiming it's for their benefit. Have you reached out to them already? The proposals come from the distros. Starting from Fedora, in the bug report. Did you read it? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Sunday, September 23, 2012 16:06:46 Thiago Macieira wrote: On domingo, 23 de setembro de 2012 13.10.32, Stephen Kelly wrote: In transition times, distros either have to be more exact (add 5.0) or change the name entirely (Qt5Core - Qt6Core). We do not want them to rename. That would be bad for everyone involved. So they need to replace the requirement in all of their control files. And all the third parties need to do it in their non-qmake and non-cmake requirement files too. Granted, there aren't many. Saying it 'won't work' is wrong. They have to do one or the other or their packages will be completely broken. That's what I'm trying to do: avoid breaking them. There seems to be misunderstanding somewhere. Let's ignore that for now though. And it doesn't solve the co-installation problem. We need both 4 and 5 to install at the same time. Why? If distros decide they want that, then they can put each in a different prefix. Why is that for us to do? Because there is only one prefix for distributions: /usr. They do not like installing elsewhere. We're not going to change 20 years of practice with our 5.0 release. So each one will do different hacks to support their systems and policies. And LSB 5 will also have an optional module that is separate, opt-in, instead of the default. How about instead we just align with everyone else's practices? We'd need to be really sure what everyone elses practices are. So far we've heard from Fedora about what they do with Qt 4 and we've heard from them that GTK+ puts version numbers in .pc file names. I think a more complete picture is needed to call it 'everyone else'. It seems like it would be nice for pkg-config files to be able to contain a maximum version number for some start-number. Is that possible? Sorry, what? I didn't understand. I was thinking that the pkg-config file itself could know the maximum version it can provide, given some starting point. Ie, a pkg-config file for Qt 5 would throw an error or not consider the package 'found' if it found Qt 6. I don't know enough about pkg-config to know if that's possible. Even if it is, it would just be 'nice' anyway, not 'needed'. It still does not make sense. How would QtCore.pc version 4.8.3 know anything about QtCore.pc 5? I'm assuming it doesn't need to. Chalk that up to me making assumptions about how pkg-config works. You must be thinking of a FindQt4 tool like cmake's, which uses pkg-config to find Qt 4. In that case, yeah, it can consider that Qt 5 is not Qt 4, and it isn't. I'm not thinking of any combination of pkg-config and cmake. But a generic pkgconfig call cannot do that because the user may have meant Qt 5. It can't consider Qt 5 not present, unless we stop installing a QtCore.pc file -- and that's what I'm calling for. ... or unless the -devel packages are not coinstallable (as is currently the case). So far we have Fedora asking for that. Can we get more input on whether they need to be coinstallable? We could try and this could be done for most distros, but it wouldn't solve the problem of source packages by third parties. What third parties? The ones linking to Qt but not using qmake or cmake. Vanishingly irrelevant imo. Why do you think it's our problem to solve and not theirs? I don't think it's their problem to solve. I think that this is a correct change to do. They won't see it as their problem because the GTK camp has already solved this problem for years. From their point of view, they'll see us as the ones breaking the rules they already have in place. And if we refuse to act, they might opt for a path of least resistance and rename our files, which in the end hurts us more than it hurts them. We only 'refuse to act' if distros are already asking us to implement your proposal and we say no for the sake of laziness. That's not what's happening here though. That's exactly what's happening. I'm bringing the proposal to the table and you're starting to resist it. I'm not really resisting it. You're re-writing the book on how to rename a library, according to your initial email. In my mind that's something to do: * cautiously * with buy-in from stakeholders and those affected and reachable * with understanding of the reasons it has to be done this way and not another So that's why I'm replying here. Currently, it's not distros proposing this. Yes it is. Did you think I came up with this on my own? In its current form and the current concrete proposal, yes. You wrote that it is the first light for the idea in words like this. A credible proposal would have to have input and buy-in from debian/suse/redhat/ubuntu packagers. Otherwise we'd just be changing things for the sake of it and claiming it's for their benefit. Have you reached out to them
Re: [Development] Co-installation library naming rules
On domingo, 23 de setembro de 2012 18.00.26, Stephen Kelly wrote: It seems like it would be nice for pkg-config files to be able to contain a maximum version number for some start-number. Is that possible? Sorry, what? I didn't understand. I was thinking that the pkg-config file itself could know the maximum version it can provide, given some starting point. Ie, a pkg-config file for Qt 5 would throw an error or not consider the package 'found' if it found Qt 6. I don't know enough about pkg-config to know if that's possible. Even if it is, it would just be 'nice' anyway, not 'needed'. It still does not make sense. How would QtCore.pc version 4.8.3 know anything about QtCore.pc 5? I'm assuming it doesn't need to. Chalk that up to me making assumptions about how pkg-config works. It reads a .pc file, compares the version numbers, then prints information. I still don't get how you want pkg-config to guess that the user meant not Qt 5 when the user didn't write 5.0. But a generic pkgconfig call cannot do that because the user may have meant Qt 5. It can't consider Qt 5 not present, unless we stop installing a QtCore.pc file -- and that's what I'm calling for. ... or unless the -devel packages are not coinstallable (as is currently the case). So far we have Fedora asking for that. Can we get more input on whether they need to be coinstallable? They need to be. That's the source of the bug report: the two versions have the same .pc file names. The ones linking to Qt but not using qmake or cmake. Vanishingly irrelevant imo. Probably. But we've been saying for 7 years that pkg-config is the official way of finding Qt. CMake's use of qmake is non-standard. You're re-writing the book on how to rename a library, according to your initial email. In my mind that's something to do: * cautiously * with buy-in from stakeholders and those affected and reachable * with understanding of the reasons it has to be done this way and not another So that's why I'm replying here. They want co-installation of all files. I'm simply making a proposal on how to achieve that now and in the future. But yeah, they need to review the proposal too. I was hoping they'd have pitched in by now. You wrote that it is the first light for the idea in words like this. The first time I've seen it phrased like that. Not the first time it's used, since I'm following existing practice of the Gtk libs. A credible proposal for me would be one which Sune/Modestas Vainus, Riddell/Harald Sitter, Will Stephenson, and maybe the unix-but-non-linux people like Raphael Kubo da Costa all buy-into. That doesn't appear to be what we have. They haven't replied yet. But this is something they should. I'm sure they're all on the kde-packager mailing list though, so you might even be able to reach them all in one go. That's a private list, so you'd have to ask them to reply/discuss here. Then that's off. If they want to package Qt, they come to us. I've called for packagers to join this list and/or the releasing mailing list more than once. I understand everyone is busy and I only posted this on Friday, so let's give them time to understand the proposal and support it, or point out the issues. In summary: I don't think it's a good idea to sprint towards an implementation of your proposal until it has credible buy-in from 'outside' of the Qt-Project. Agreed. I'm not really opposed to it and won't stand in the way of a credible implementation of it. My mails here are an attempt to understand why your proposal is the only/best way. I think the proposal spoke for itself. Goal: co-installation of all files. The current Qt Project's position is that we don't support that. We require Qt to be installed in different prefixes and we don't like our tools being renamed (including qmake). It works and we all know it does -- I have about 10 different checkouts / builds of Qt on my laptop and they never stand on each other's way. We can continue down that road and packagers will do what they've done to Qt 4, multiplied by several more files. Or we can be a good citizen and just do what everyone else does. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
Thiago Macieira schreef op vr 21-09-2012 om 16:47 [+0200]: Include the major version number (5) in all library base names Hi, As the person who filed the mentioned QT-BUG in the first place I would like to let you know that I'm +1 to the proposal from Thiago. For the people who don't know me yet: I'm a member of the Fedora MinGW group and we provide cross-compiled binaries of Qt for the win32 and win64 targets so users can easily cross-compile their software on a Linux host and run them on Windows (or Wine). On IRC I've been discussing this subject with Kevin Kofler (Fedora KDE group) and he also +1's the proposal from Thiago Some days ago I started on packaging the entire Qt5 stack and stumbled across the fact that by default Qt4 and Qt5 can't be installed in the same prefix as there are various file name conflicts. Therefore I had to do some additional patching (like https://codereview.qt-project.org/34981 ) and manual renames to make it possible to co-install Qt4 and Qt5. The resulting packages can be found at https://bugzilla.redhat.com/showdependencytree.cgi?id=3D858058 The reason why we want to be able to co-install Qt4 and Qt5 is because all packages in Fedora are expected to follow the FHS as close as possible and the packaging rules state that no packages are allowed to conflict with each other. A suggestion was made in this thread that distro's should use separate prefixes to install Qt4 and Qt5. This will be a no-go as in that situation you will force all users of Qt4 or Qt5 to apply distribution-specific hacks to get their Qt-using application built. Examples of these hacks are: For qmake: - Users having to manually call $some_random_prefix/bin/qmake to select either Qt4 or Qt5 instead of having the qmake binary available in their default path For pkg-config: - Manually setting PKG_CONFIG_PATH to point to the pkg-config folder where either the Qt4 or Qt5 pkg-config files are stored As mentioned earlier in this thread the gtk folks have been using versioned library names for a very long time already and due to this the introduction of gtk3 itself was quite painless (just speaking about gtk3 here, not gnome3). All gtk-using packages are supposed to use pkg-config to detect the compiler flags for gtk. The gtk2 library has been providing a pkg-config file named 'gtk+-2.0.pc' and the gtk3 library is providing a pkg-config file named' gtk+-3.0.pc'. As these names don't conflict all gtk2-using packages rebuilt fine even when gtk3 is installed. Packages which want to use gtk3 can indicate so by using pkg-config to check for 'gtk+-3.0'. In my opinion the Qt project should make it possible to co-install Qt4 and Qt5 in the same prefix. If the Qt project refuses to do so then this will result in distributions applying random patches to get Qt5 working correctly on their distribution. This will lead to more distribution-specific hacks and will make it more hard for you guys to diagnose and resolve bugs (as you're not aware of distribution-specific patches). Now various distributions could start a collaboration to come to uniform packaging guidelines for the Qt package (naming of qmake, installation location, etc..) but why not solve the problem at the level where it's supposed to be fixed, upstream? I don't think it's fair to move the problem to the distributions. If the library name stays as is you're forcing a lot of additional work on us package maintainers while it can be resolved quite easily and now is the perfect time to do so (right before the release of a major new version of Qt) Kind regards, Erik van Pienbroek Fedora MinGW SIG ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Friday, September 21, 2012 16:47:11 Thiago Macieira wrote: Rationale: -- This is a rewriting of the book in how to name a library. It seems like it might be something to bring up in a wider scope (with distros for example). This isn't Qt specific. Has it been an issue before? Why solve it now? == Enter other tools == As was shown by CMake months ago, we cannot have the Qt 5 packages called Qt as those conflict with the ones in Qt 4. For clarity, I guess you mean that we chose not to use find_package(Qt VERSION 5) We could have, but for several reasons (for example, symmetry with find_package(Qt4), easier to implement without having to think about conflicts, etc). but instead we chose to have multiple separate modules like this: find_package(Qt5Core) We could also have used find_package(QtCore) but I couldn't build concensus to remove the major version number from there. Of course, to disabmiguate, users could have used find_package(QtCore VERSION 5) or find_package(QtCore VERSION 6) as desired. Having the version number in the name in the case of the CMake files is not really required, but I gave up trying to build consensus on that. Buildsystems based on pkgconfig will often have a requirement of the form: QtCore = 4.6 QtGui = 4.6 or even simply: QtCore QtGui It is also possible to specify QtGui 5.0. Any distro where that is needed, but not present is a bug in the distro. Those requirements do match the Qt 5 libraries: $ pkg-config --libs QtCore \= 4.6 QtGui \= 4.6 -L/home/thiago/obj/qt/qt5/qtbase/lib -lQtCore -lQtGui $ pkg-config --libs QtCore \= 4.6 QtCore \ 5.0 Requested 'QtCore 5.0' but version of Qtcore is 5.0.0 Whether that is correct or not is unknown to pkg-config. But it is known to the user of pkg-config. It could be right if the application has already been ported to Qt 5. In the case of most applications existing today, it is incorrect. But it could be right for other libraries. For example, for libpng: $ pkg-config --libs libpng \= 1.2 -lpng15 It seems like it would be nice for pkg-config files to be able to contain a maximum version number for some start-number. Is that possible? The fact that our pkg-config files have the same name also impacts the co- installability of Qt 4 and Qt 5, and a little more: Linux distributions *will* carry Qt 4 for a number of years to come (they still have Qt 3). Therefore, they must be able to at least have both sets of packages in their repositories. The problem comes when their buildsystems make reference to pkg- config files, such as in RPM-based distros: BuildRequires: pkgconfig(QtCore) I don't know anything about RPM, but I would be surprised if they can't specify versions there. If they can't, then that's a global bug for them, not a local one for us. Since the distribution contains packages for both versions of QtCore, it is now ambiguous which one would be selected for building. From what I know about distros, they are capable of handling versions like this, so this is a solved problem, no? Selecting the 5 version now would be wrong, just as selecting version 4 in a few years' time. This is a distro problem to solve. == Proposal == The library naming rules must be modified. Is this the first light for this proposal, or have you brought this to distros attention already? Why do you think it's our problem to solve and not theirs? Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ** Qt Developer Conference: http://qtconference.kdab.com/ ** signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Fri, Sep 21, 2012 at 04:47:11PM +0200, Thiago Macieira wrote: This is long, so I'll give you my recommendation first. If you agree with me, you don't have to read the rest. If you disagree, you have to read my arguments. fwiw, this refers to https://bugreports.qt-project.org/browse/QTBUG-27137 - i stand by my last comment. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On sexta-feira, 21 de setembro de 2012 17.33.01, Stephen Kelly wrote: On Friday, September 21, 2012 16:47:11 Thiago Macieira wrote: Rationale: -- This is a rewriting of the book in how to name a library. It seems like it might be something to bring up in a wider scope (with distros for example). This isn't Qt specific. Has it been an issue before? Why solve it now? Because we're about to release 5.0 and these problems need to be solved. I forgot to link: here's where the discussion originated: https://bugreports.qt-project.org/browse/QTBUG-27137 but I couldn't build concensus to remove the major version number from there. Of course, to disabmiguate, users could have used find_package(QtCore VERSION 5) or find_package(QtCore VERSION 6) This is the right way of doing it, provided that the VERSION is mandatory. Which is why I am recommending that it be hardcoded in the name instead. as desired. Having the version number in the name in the case of the CMake files is not really required, but I gave up trying to build consensus on that. Buildsystems based on pkgconfig will often have a requirement of the form: QtCore = 4.6 QtGui = 4.6 or even simply: QtCore QtGui It is also possible to specify QtGui 5.0. Any distro where that is needed, but not present is a bug in the distro. This is not a permanent solution nor does it work now. There are three problems it doesn't solve: *Currently*, the packages and dependencies are listed like I listed. We cannot require that everyone replace everything now. Won't work. Further, it won't work for QtGui 6.0 since that would select either 4 or 5. People would have to write QtGui = 4.6 QtGui 6.0, but as I said, reality is different. And it doesn't solve the co-installation problem. We need both 4 and 5 to install at the same time. Those requirements do match the Qt 5 libraries: $ pkg-config --libs QtCore \= 4.6 QtGui \= 4.6 -L/home/thiago/obj/qt/qt5/qtbase/lib -lQtCore -lQtGui $ pkg-config --libs QtCore \= 4.6 QtCore \ 5.0 Requested 'QtCore 5.0' but version of Qtcore is 5.0.0 Whether that is correct or not is unknown to pkg-config. But it is known to the user of pkg-config. Who didn't think this far ahead. This is the right way to do it, but two of the problems remain. It could be right if the application has already been ported to Qt 5. In the case of most applications existing today, it is incorrect. But it could be right for other libraries. For example, for libpng: $ pkg-config --libs libpng \= 1.2 -lpng15 It seems like it would be nice for pkg-config files to be able to contain a maximum version number for some start-number. Is that possible? Sorry, what? I didn't understand. The fact that our pkg-config files have the same name also impacts the co- installability of Qt 4 and Qt 5, and a little more: Linux distributions *will* carry Qt 4 for a number of years to come (they still have Qt 3). Therefore, they must be able to at least have both sets of packages in their repositories. The problem comes when their buildsystems make reference to pkg- config files, such as in RPM-based distros: BuildRequires: pkgconfig(QtCore) I don't know anything about RPM, but I would be surprised if they can't specify versions there. If they can't, then that's a global bug for them, not a local one for us. They can. But we can't require all distros to patch all their .spec files to say 5.0 and = 5.0 in other places. We could try and this could be done for most distros, but it wouldn't solve the problem of source packages by third parties. == Proposal = The library naming rules must be modified. Is this the first light for this proposal, or have you brought this to distros attention already? First light putting it to words like this. However, note that glib family libs *already* follow this convention and have done so for years, since their 2.0 release. I just don't think it has been codified like I've done. Why do you think it's our problem to solve and not theirs? I don't think it's their problem to solve. I think that this is a correct change to do. They won't see it as their problem because the GTK camp has already solved this problem for years. From their point of view, they'll see us as the ones breaking the rules they already have in place. And if we refuse to act, they might opt for a path of least resistance and rename our files, which in the end hurts us more than it hurts them. See the qmake vs qmake-qt4 issue, just like the LSB 4 solution that can't co-install Qt 3 and Qt 4. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing
