> 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
> 
>

-- 
kubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel

Reply via email to