> 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.
"Stuck" is exactly why we need to put our heads together and come up with a solution. "Stuck" is not ok. - 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
