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

Tue Nov 25 17:19:43 UTC 2014

> On Nov. 18, 2014, 3:19 p.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)
> 
> Jeremy Whiting wrote:
>     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.
> 
> Ivan Romanov wrote:
>     You don't. You add.
>         find_package(Qca NAMES Qca-qt5 Qca-5 Qca-bla-bla-bla)
>         
>     Package always names Qca. QCA is wrong. Qca-qt5 is wrong too. By fact you can use just `find_package(Qca-qt5)` it will work but it is not correct. In this case you get `Qca_qt5_LIBRARY` not `Qca_LIBRARY`.
>     
>     Look at [qt5-qtbase](http://pkgs.fedoraproject.org/cgit/qt5-qtbase.git/tree/qt5-qtbase.spec#n450) package in Fedora. In Fedora Qt5 uses /usr/lib{%suffix}/qt5 for most of Qt5 stuff (not regular HFS). But the most important in our case Fedora makes -qt5 suffix for Qt5 developer tools. Qt5 do not do that. It's not a library. Something another. I just say that it is a normal practice when maintainer of package do required hacks to avoid conflicts.
>     
>     > 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.
>     
>     Do fork it's not problem. If you sure that hard-coded alternative name it is good reason for this. And if you want to support this library. No any problems.
> 
> Michael Palimaka wrote:
>     How can we expect every consumer to do find_package(Qca NAMES Qca-qt5 Qca-5 Qca-bla-bla-bla)? There needs to be a sane upstream default.
> 
> Ivan Romanov wrote:
>     > How can we expect every consumer to do find_package(Qca NAMES Qca-qt5 Qca-5 Qca-bla-bla-bla)?
>     
>     cmake shows warning. It's should be enough.
>     
>     
>     > There needs to be a sane upstream default.
>     
>     There is sane upstream default is Qca.
> 
> Michael Palimaka wrote:
>     What does a warning have to do with anything? Are you expecting every Qca consumer to enumerate every possible suffix and just hope that it was built with one of them, or do you seriously expect downstream to patch every single Qca consumer?
> 
> Ivan Romanov wrote:
>     There are two ways handle this.
>     Maintainer of package will report bugreport to consumer to add new suffix or he can just write very simple patch. To use correct suffix for him distro. Patches are OK. The most of packages uses patches or extra actions to build and install soft not just `./configure && make && make install`. Or you can provide some QCA_SUFFIX in your consumer to allow maintainer to set correct suffix.
> 
> Ivan Romanov wrote:
>     My task/issue is give your a way to set all what you want. Your task/issue just use them all. It is my point view. If that way what I provided you is not your fit. I will work next to improve it. But don't ask me to change defaults.
> 
> Martin Klapetek wrote:
>     > Patches are OK.
>     
>     No they are not.
>     
>     > The most of packages uses patches or extra actions to build and install soft
>     
>     No they do not.
>     
>     Moreover, you still seem to be missing the key issue - this way, you put _extra_ _work_ on _everybody_. Why do you want to put _extra_ _work_ on _everybody_ when you can help _everybody_ by accepting a single-line patch. That just makes no sense and it is not really a team-play. Ask any packager in the world what they think about downstream patches (and soo many have replied here and in the other). Why make everyone's life harder... :(
> 
> Michael Palimaka wrote:
>     Other packagers, are you interested in a shallow fork? I think it's pretty clear at this point that Ivan is not grounded in reality and we will not get anything other than the middle finger from him.
> 
> Ivan Romanov wrote:
>     > extra work on everybody
>     
>     Add `-DQCA_SUFFIX=qt5` is not extra work. It is normal work for any maintainer.
>     
>     > That just makes no sense and it is not really a team-play
>     
>     In team-play I can have own opinion. I mustn't to do all what somebody says me. You not my employer. I do it for free just as my hobby not more. I started because nobody care about QCA and I wanted to port psi to Qt5.
> 
> Ivan Romanov wrote:
>     Michael, just do not use original QCA do fork if you want. You can think that I shows `middle finger`. If you don't agree with my work you can drop all my patches, write own cmake scripts and port to Qt5 again. It is not a problem. If you really think so.
> 
> Michael Palimaka wrote:
>     It is extra work. No other package requires that sort of nonsense.
> 
> Michael Palimaka wrote:
>     As I've previously mentioned, it's not feasible for me to support coinstalled Qt4/Qt5 QCA in its current form - so no, we won't be using it (we have no choice), but thanks anyway.

Can everyone take a calm breath?

Suggesting to fork over such a trivial issue is a bit silly, IMHO. Especially considering that this is a cryptographic library, even a small chance that an eventual fork loses a patch could have pretty bad results, we don't want more issues to security at kde.org. :-)

Ivan: Is there any specific reason that you don't want this change? If there is some Psi source or build system that needs to be changed, just tell me (or us), and I'll try to come up with a patch. :-)

Would defaulting to setting the suffix for Qt5 be acceptable, with an option to remove/change it?

As an application developer I would prefer the name to be the same across distros, to make it easier for me. But I respect your decision, and with the cmake warning hopefully no distros decide to chose something else.

- Martin Tobias Holmedahl

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

On Nov. 18, 2014, 2:53 p.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, 2:53 p.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/20141125/6dea0e20/attachment-0001.html>