> 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 [email protected]. :-) > > 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.
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. - Valorie ----------------------------------------------------------- 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 > >
-- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
