Review Request 121168: Ensure a different so-name for Qt4 and Qt5

Jeremy Whiting jpwhiting at kde.org
Mon Nov 24 21:01:26 UTC 2014



> On Nov. 18, 2014, 8:19 a.m., Ivan Romanov wrote:
> > It won't be fixed. Change major version is really bad idea.
> > Close review request and read INSTALL.
> 
> Aleix Pol Gonzalez wrote:
>     I don't understand your review.
>     
>     Why is it a bad idea? What do you want me to see in INSTALL?
> 
> Albert Astals Cid wrote:
>     Changing major version is a very good idea, qca compiled with Qt4 and qca compiled with Qt5 are totally incompatible with eachother, so they should not have the same major version.
>     
>     Why do you say they should have the same major version number?
> 
> Ivan Romanov wrote:
>     > Why is it a bad idea? What do you want me to see in INSTALL?
>     
>     QCA_SUFFIX
> 
> Ivan Romanov wrote:
>     > Changing major version is a very good idea
>     
>     Ok, how to have both qca-devel and qca-qt5-devel subpackages in one system? Both packages in this case will have libqca.so but first => libqca.so.2 and second => libqca.so.3 . Do you can resolve this issue? Why you can't use QCA_SUFFIX? I give you all tools to install qca and qca-qt5 in parallel. Just use them. And don't argue with me.
> 
> Albert Astals Cid wrote:
>     > And don't argue with me.
>     
>     Really? This is your way of treating contributors?
> 
> Ivan Romanov wrote:
>     This question allready was discussed before. Requester can't answer why he can't just use QCA_SUFFIX. And why I must use hard-coded another library. But he was sure that I must do as he said. I will try to find that review request.
> 
> Ivan Romanov wrote:
>     Is there any find tool in git.reviewboard.kde.org
> 
> Ivan Romanov wrote:
>     https://git.reviewboard.kde.org/r/119939/
> 
> Ivan Romanov wrote:
>     You can explain me why you can't use QCA_SUFFIX or maybe somebody prohibits you to use it?
> 
> Ivan Romanov wrote:
>     Or maybe there is standard which force me to change major version?
> 
> Martin Klapetek wrote:
>     Speaking of not answering questions or explaining...the RR you linked have 5 people from different major distributions asking questions which you have left unanswered and also suggesting you *should* do that and you did not /explain/ why you would not accept it.
>     
>     I don't know what standard you keep looking for...those comments are from packagers. And packagers are the people that deal with these things every single day; they get the stuff you create to users. They know the best. There's nothing to argue. If anyone should not argue, it's you with them, really.
>     
>     As for this RR, note Dan's reply in the other -- "I'd like to point out that soname bump is usually not enough. It will prevent conflict of the base package, but it will lead to conflicts with -devel packages, which install the library without soname."
> 
> Albert Astals Cid wrote:
>     > This question allready was discussed before. Requester can't answer why he can't just use QCA_SUFFIX. And why I must use hard-coded another library. But he was sure that I must do as he said. I will try to find that review request.
>     > https://git.reviewboard.kde.org/r/119939/
>     
>     
>     Well I wasn't aware of that review request, but even if i was, what's the reason to be impolite and say "don't argue with me"? Anyway, i'm not interested in discussing with impolite people. Enjoy!
> 
> Ivan Romanov wrote:
>     In this case **NO** any standarts which I should/must follow. Case when from the same sources can be compiled some not ABI compatibles libraries is specific. No standart way to handle this. So IMO library name shouldn't be depended from any other libraries against which it compiled. So I use by default qca name. But I know what sometimes distros provides some versions of one library. For this case I did QCA_SUFFIX it allows to have various version on single library installed in parallel. I think it will be enough.
> 
> Andrey Bondrov wrote:
>     QCA_SUFFIX is a good way to have both Qt4 and Qt5 qca libraries installed, including both development packages. Here is how I build Qt5 version of qca: https://abf.rosalinux.ru/openmandriva/qca2-qt5/blob/master/qca2-qt5.spec
> 
> Andrey Bondrov wrote:
>     Could be nice to have qt5 as the default (=recommended) QCA_SUFFIX for Qt5 build. Otherwise we may end with some blobs built for Ubuntu (or another distro) missing required qca2 library only because of different soname/filename.
> 
> Martin Klapetek wrote:
>     --> https://git.reviewboard.kde.org/r/119939/ - that's what that RR is about.
> 
> Ivan Romanov wrote:
>     Andrey, use stable release http://delta.affinix.com/download/qca/2.0/qca-2.1.0.tar.gz
> 
> Ivan Romanov wrote:
>     Andrey, QCA_INSTALL_IN_QT_PREFIX is not cache variable so you can't set this in command line. qca-gnupg requires gnupg package (prefer 1.4 version) I think should be added `Requires: gnupg`. Also there are documentation. I think it will be good to give these to developers `make doc && cp -r apidocs/html /some/path`
> 
> Ivan Romanov wrote:
>     Andrey, I will add suitable warning to cmake for users who build on Linux for Qt5 without QCA_SUFFIX. Please provide me text for this warning.
> 
> Andrey Bondrov wrote:
>     Thanx for your advices, I updated package to 2.1.0 stable and adjusted spec file. As for the warning, I guess this text is OK: "You don't have QCA_SUFFIX set. Please note that the recommended way of building Qt5 version of qca for Linux distributions is to set QCA_SUFFIX to qt5 (-DQCA_SUFFIX=qt5)."
> 
> Ivan Romanov wrote:
>     Andrey, you build docs but didn't to copy to %{buildroot}. Also use QCA_MAN_INSTALL_DIR to set properly path for manpages.
> 
> Andrey Bondrov wrote:
>     Ivan, I use "%doc build/apidocs" inside devel package's %files instead of copying build/apidocs to buildroot. And thanx for the hint with QCA_MAN_INSTALL_DIR :-)
> 
> Hrvoje Senjan wrote:
>     >QCA_SUFFIX is a good way to have both Qt4 and Qt5 qca libraries installed, including both development packages.
>     
>     Hm, but both development packages cannot be installed at the same time. The CMake files are installed into the same dir name for both Qt4 and Qt5 builds, regardless of the QCA_SUFFIX
> 
> Ivan Romanov wrote:
>     Renaming config files is not correct. I can't just use suffix for them. find_package can handle only with single name. I don't knot how to handle with this. Maybe there is a way to distinct Qt version in qca config files.
> 
> Michael Palimaka wrote:
>     Why is renaming the package/config file incorrect? Numerous packagers suggest you adopt an approach used by pretty much every major library supporting both Qt4 and Qt5, and you consistently refuse to even entertain it. We're forced to recommend to our users to avoid software using QCA because it's just not possible to support properly.
> 
> Aleix Pol Gonzalez wrote:
>     Well, the reason why you don't want to tie the Config file name to the suffix is simple. If you did that, you'd make developers to tie their source code (i.e. find_package(QCA-qt5)) to whatever the distribution decided to call the QCA_SUFFIX. FWIW, I don't think it should be up to the packager to define what it's called, the only reason we need the suffix is because we need co-installability of the library between Qt4 and Qt5.
> 
> Michael Palimaka wrote:
>     That's correct, I meant renaming in general (ie. to a fixed string, upstream)
> 
> Ivan Romanov wrote:
>     > Why is renaming the package/config file incorrect?
>     
>     My failure. I read cmake documentation again. So `find_package` has `NAMES` option what can contains alternative possible config names. So I can freely use `QCA_SUFFIX` for cmake config files too.
> 
> Ivan Romanov wrote:
>     Commits
>     [cmake: warn user when QCA_SUFFIX is not set](http://quickgit.kde.org/?p=qca.git&a=commitdiff&h=2c58be171e8478f03d8a724640f40e36826c6893&hp=25860ff244205b7cc61fc5c8ed06bcbe9f12957f)
>     [cmake: apply QCA_SUFFIX for cmake config module names](http://quickgit.kde.org/?p=qca.git&a=commitdiff&h=66447d0454591f4c1deb5f4c988c6027194b1335)

Ivan,

I appreciate the two commits you made to simplify things, however it seems that's not enough. For example say I want to create an application (or build an existing one) that uses qca built for qt5. If I add find_package(QCA-qt5) it will work only on distributions who built qca with -DQCA_SUFFIX=-qt5 but not another distro that built with -DQCA_SUFFIX=5 or another that used -DQCA_SUFFIX=qt5. This is very unfortunate. Many many packagers have commented on this review and the other review that a solution within qca sources itself is ideal and wanted. You have repeatedly ignored questions of why you are against such a change besides asking for some standard that will never exist. If you would like to help users of qca use qca you should propose a solution or accept one of these solutions that has already been presented to you. I fear if you do neither of these a fork of qca may happen at some point so we can get past this issue and move on.


- Jeremy


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121168/#review70590
-----------------------------------------------------------


On Nov. 18, 2014, 7:53 a.m., Aleix Pol Gonzalez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121168/
> -----------------------------------------------------------
> 
> (Updated Nov. 18, 2014, 7:53 a.m.)
> 
> 
> Review request for Kubuntu and Ivan Romanov.
> 
> 
> Repository: qca
> 
> 
> Description
> -------
> 
> Qt4 and Qt5 versions can't have the same so-name. An application compiled against Qt4 won't work if suddenly it finds a Qt5 dependency.
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 7adacf1 
> 
> Diff: https://git.reviewboard.kde.org/r/121168/diff/
> 
> 
> Testing
> -------
> 
> Stills builds, things didn't seem to break.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20141124/9eae98f0/attachment-0001.html>


More information about the kubuntu-devel mailing list