Review Request 121168: Ensure a different so-name for Qt4 and Qt5
Aleix Pol Gonzalez
aleixpol at kde.org
Thu Nov 27 04:26:24 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.
>
> Martin Tobias Holmedahl Sandsmark wrote:
> 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.
>
> Ivan Romanov wrote:
> > Ivan: Is there any specific reason that you don't want this change?
>
> Martin. As I allready had mentioned many times. Only reason that is not correct to change library (and other stuff) name. Library name mustn't be related from another libraries. Also in common case every distros provides only one version of each library. As I know it is Linux philosophy. When need to provide another version of some library it is non standard case. In our case we have Qt4 library which is default (and standard) and Qt5 library which is non-standard but distrod provide this library to make soft transition and allow all software migrage to Qt5 without big stress. So from this point of view it is not correct to support alternative library names for cases Qt4 and Qt5 installed in parallel. So next my task is provide a way to do soft transition to Qt5. I did this when added QCA_SUFFIX which must solve all problems. Also I see in the future when will no be Qt4 and will be only Qt5. In that time qt5 suffix will be nonsense. Also suffix nonsense on Windows and Mac OS X where all libraries is bundled in app.
>
> Make resume. Suffix now is a hack to do soft migration to Qt5. In the future it won't be used.
>
> > If there is some Psi source or build system that needs to be changed
>
> No any psi-related issues.
>
> > But I respect your decision.
>
> Very big thanks!
>
> Martin Tobias Holmedahl Sandsmark wrote:
> > In our case we have Qt4 library which is default (and standard) and Qt5 library which is non-standard but distrod provide this library to make soft transition and allow all software migrage to Qt5 without big stress.
>
> Yes, this is what archlinux (the distro I use) is doing at the moment; the official QCA package is just the normal Qt4 version without any suffix (and this is what everything supported is built against), the qt5 version is only available in the unofficial, user-controlled AUR repository, and there with the suggested qt5 suffix.
>
> > Also I see in the future when will no be Qt4 and will be only Qt5. In that time qt5 suffix will be nonsense.
>
> I think the problem some of the distro people are having is that if they now want to ship both qt4 and qt5 applications using QCA, they will have to rebuild everything that is built against qca with the qt5 suffix against qca without the suffix in the future, or continue using the suffix forever (which is what I think they are going to do).
>
> > Also suffix nonsense on Windows and Mac OS X where all libraries is bundled in app.
>
> I agree, this is mostly an issue for applications on Linux/linux distributions.
>
>
> But to summarize; I agree that using a qt5 suffix is pretty ugly and not very elegant, but a pragmatic solution to the problem on linux would be to add the suffix by default (especially since it seems like a lot of distributions are going to do it anyways). But you're the one maintaining and doing most of the work on QCA, so it's your call.
>
> Lastly, thank you for working on QCA, caring enough to respond to people, and implementing the current suffix solution. :-)
>
> Valorie Zimmerman wrote:
> Hello folks, the Community Working Group has been asked to step in here. This is an important issue, affecting a lot of people. I would like to thank each of you who weighed in here, because you all care deeply about the KDE community and keeping our software excellent. I'm seeing a bit of arguing from position here on both "sides" though.
>
> What is important is solving the problem. Please can we get to a dialogue where the goal is crafting a solution which will work for everyone?
>
> Again, thank you everyone reading this.
>
> Ivan Romanov wrote:
> Will work and will satisfy is not the same. Current solution is work for everyone (nobody says that it's not working). In the most it is a principial question. My opinion that I as a developer may decide do something or not to do with my library (I said 'my' because currently I single developer of QCA). Community decide that I must do what they say me. It is no technical question so it hasn't single right answer. Sad but true.
>
> As I know philosophy of open-source. Community can make request for some feature and I as developer can agree, refuse, partially agree or use own solution. In the same time community can't demand from me nothing. They did request me. I answered many times. I made detailed explanation why I refuse. Also I said what I need to agree. Also I said what I can/will do to solve issue of current review request... Community not agree with me. And so we stucked.
>
> Valorie Zimmerman wrote:
> "Stuck" is exactly why we need to put our heads together and come up with a solution. "Stuck" is not ok.
>
> Ivan Romanov wrote:
> Do you have any specific suggestions?
>
> Jeremy Whiting wrote:
> Ivan, I'm sorry I suggested a fork for something so small. I thought that would convey to you how important this issue of being able to have two instances of the library on one system is. Some suggestions to get unstuck have been given on this and the other review request. You turned both down, some without much explanation, but that's your choice. Do you have any suggestions? What is needed is a way to have qt4 and qt5 versions of qca installable (maybe QCA_SUFFIX is enough) and the header files need to not conflict also.
>
> Ivan Romanov wrote:
> I haven't any suggestions. I'm afraid I can help you. It's not a technical dialogue. I am powerless here.
>
> Jeremy Whiting wrote:
> Eh? the problem is a technical one. There is a requirement to have qt4 and qt5 based instances of qca on the same system. Including header files to build applications against. What is your suggestion for solving this?
>
> Ivan Romanov wrote:
> You still didn't say why you can't use QCA_SUFFIX or why you can't use own patch with hard-coded suffix. Or you also have option to make own source tarball with the integrated patch. Your linux don't allow use it? Or where this **tehnical** problem? You can say for example: my keyboard hasn't `5` key so it's impossible for me to type suffix. Now I understand it is a tehnical problem. I will suggest your to change your keyboard in that case. It will be tehnical sollution of tehnical problem.
>
> In this case you have all ways to solve your problem (to have both qca installed in one Linux system) but you don't want to use them. And you don't say what don't allow to use them. It's not a tehnical problem. This principle. I can't help you with your principle.
>
> Ivan Romanov wrote:
> Is there any way to close this nonsense conversation?
>
> Ivan Romanov wrote:
> So use QCA_SUFFIX, read INSTALL file. Try to use options from INSTALL file. And only if you will get specific issues and can show me them (some logs). Only in that case write bugreport or reviewrequest. I will work on those. So I leave this nonsense conversation and will write nothing here.
>
> Martin Klapetek wrote:
> > You still didn't say why you can't use QCA_SUFFIX or why you can't use own patch with hard-coded suffix
>
> I would like to reiterate all the points then.
>
> * everyone would use different suffix, making things non-portable
> * you can't expect everyone in the world to do "find_package(Qca NAMES Qca-qt5 Qca-5 Qca-bla-bla-bla Qca-every-single-possible-combination)" that is simply nonsense
> * every packager of every distrubtion has to maintain downstream patches/special configurations, they all expressed here that they do not want to do this
> * it is not true that every package in distribution has custom patches
> * distributions need to ship qt4 and qt5 applications together and may have to do so forever (for example if some app will not get ported to qt5 but will stay qt4)
> * we have other libraries in the world which set different library suffix automatically depending on qt5 env being used (for example phonon4qt5)
> * if you do not set the suffix manually, the qt5 library will have the same name as the qt4 and applications will crash because of binary incompatibilities
> * it is also not correct that library name must not be changed; it's actually quite the opposite because of the above
> * you put a warning and a recommendation into cmake, but why recommend A and do B; if you recommend something it means the user himself made a concious choice about doing things differently, that's not the case here
> * there was also an argument that not all software in the world can be built using "configure && make && make install", well yes, but it could if we didn't have to deal with reviews like this
>
> All of the above (and perhaps more) could be simply solved by one single change in CMakeLists.txt. That's all it takes.
>
> Eike Hein wrote:
> Ivan,
>
> it's a technical problem because QCA is a component of a system, and the goal is for all components to act together to make that system efficient to develop and use. That provides a guideline to make certain engineering decisions; it gives a target to optimize for. This is the reason for these suggestions - the idea is to make a change in QCA that saves complexity and waste of effort in other layers of the system. QCA would be a superior library for it.
>
> On the social/community side, it's worth noting why "common ownership" is listed on https://manifesto.kde.org/. "Common ownership" is so important because it makes people feel responsible for the code they contribute to, and want to look after it and improve it. It's clear you feel that way thanks to your contributions, so you understand this well. But consider that this thread is about others wanting to contribute in QCA, and it's better for QCA if you can inspire this mindset in others. And that's the true job of maintainers - to facilitate the work of others. That does mean saying "No" when the consequences of a contribution would endanger that goal, but I don't see how this is the case here. The proposed change would make QCA easier to use.
>
> Valorie Zimmerman wrote:
> Truth be told, I am truly conflicted here. I feel very strongly that Ivan deserves respect and thanks for his work in maintaining Qca. And I feel the pain of my Kubuntu brethren who are suffering as they try to patch and make Qca work in their packaging.
>
> I get that maintainers want their applications, libraries, frameworks or whatever to be technically *perfect*. And I see that all down the line all the folks working with CI systems, doing testing, doing releases, doing packaging, want the same thing - a perfect product out the door to our users.
>
> So please, let us all think of EVERYONE in the supply line. Qca is not the issue; our users experience is the issue. How can we make the entire process excellent for everyone? Right now, it is the opposite of excellent. I don't know technically which patch would be the best way forward, but we need a way forward, sooner rather than later.
>
> Having a virtual fork in *every distribution* seems the worst possible outcome possible.
>
> I appeal to each person involved in this discussion to put on your thinking hat and let's come up with something that is good for ALL of us.
Hi Valorie, thanks for putting some order.
A pragmatic approach could be to look into how others have solved the issue of releasing the same library both with Qt4 and Qt5, like QCA:
* telepathy-qt: http://cgit.freedesktop.org/telepathy/telepathy-qt/tree/CMakeLists.txt
* appstream-qt: https://github.com/ximion/appstream/blob/master/qt/CMakeLists.txt#L14
* packagekit-qt: https://github.com/hughsie/PackageKit-Qt/blob/master/CMakeLists.txt#L29
These are the ones that popped in my head now. I hope this helps.
- Aleix
-----------------------------------------------------------
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/20141127/9e02a853/attachment-0001.html>
More information about the kubuntu-devel
mailing list