As-is, qt4-qsa installs files into the following invalid locations: %_libdir/qt4/%{_lib} %_libdir/qt4/mkspecs/ When it *should* be using %_libdir %_datadir/qt4/mkspecs respectively patches forthcoming.
Created attachment 138365 [details] workaround hard-coded uses of $QTDIR
Created attachment 138366 [details] specfile patch to use QT_INSTALL patch and fix remaining path issues
fixed
Created attachment 138411 [details] The build log
The patch will not work, because the lib file and the mkspec file get lost.
While not perfect, the patch indeed WORKSFORME, and nothing appears to "get lost", unless your idea/definition of "get lost" is different than mine. (: Here's the file list output of my mock build (on fc6/i386) using the patch: $ rpm -qlp qt4-qsa-1*.rpm /usr/lib/libqsa.so.1 /usr/lib/libqsa.so.1.2 /usr/share/doc/qt4-qsa-1.2.1 /usr/share/doc/qt4-qsa-1.2.1/LICENSE.GPL /usr/share/doc/qt4-qsa-1.2.1/README /usr/share/doc/qt4-qsa-1.2.1/changes-1.2.1 $ rpm -qlp qt4-qsa-devel-1*.rpm /usr/include/qsaglobal.h /usr/include/qsconfig.h /usr/include/qseditor.h /usr/include/qsinputdialogfactory.h /usr/include/qsinterpreter.h /usr/include/qsobjectfactory.h /usr/include/qsproject.h /usr/include/qsscript.h /usr/include/qsutilfactory.h /usr/include/qsworkbench.h /usr/include/qswrapperfactory.h /usr/lib/libqsa.so /usr/share/qt4/mkspecs/features/qsa.prf /usr/share/doc/qt4-qsa-devel-1.2.1 ...
take a look in the build log, you fill find, that package don't contains the libs:( using mock will will get an rpm package without the lib.
(BTW, I did use mock on comment #6 and it did include the lib) Further, if it your build in comment #4 indeed didn't include the libs, then the build would have *failed* because the following bits in %files would have been missing/not-found: %files ... %{qtlib}/libqsa.so.* %files devel ... %{qtlib}/libqsa.so
I have try it 6 timses. The rpm files don't have any libs:( It only contains the doc files, the include files and the links. but not the binary lib:( And when look in the log file you will find the problem. cp: cannot create regular file `/usr/share/qt4/mkspecs/features/qsa.prf': Permission denied chmod: cannot access `/usr/share/qt4/mkspecs/features/qsa.prf': No such file or directory ln: creating symbolic link `/usr/include/qsaglobal.h' to `/builddir/build/BUILD/qsa-x11-opensource-1.2.1/src/qsa/qsaglobal.h': Permission denied ln: creating symbolic link `/usr/include/qsobjectfactory.h' to `/builddir/build/BUILD/qsa-x11-opensource-1.2.1/src/qsa/qsobjectfactory.h': Permission denied ln: creating symbolic link `/usr/include/qswrapperfactory.h' to `/builddir/build/BUILD/qsa-x11-opensource-1.2.1/src/qsa/qswrapperfactory.h': Permission denied ln: creating symbolic link `/usr/include/qseditor.h' to `/builddir/build/BUILD/qsa-x11-opensource-1.2.1/src/qsa/qseditor.h': Permission denied ln: creating symbolic link `/usr/include/qsproject.h' to `/builddir/build/BUILD/qsa-x11-opensource-1.2.1/src/qsa/qsproject.h': Permission denied ln: creating symbolic link `/usr/include/qsinterpreter.h' to `/builddir/build/BUILD/qsa-x11-opensource-1.2.1/src/qsa/qsinterpreter.h': Permission denied ln: creating symbolic link `/usr/include/qsinputdialogfactory.h' to `/builddir/build/BUILD/qsa-x11-opensource-1.2.1/src/qsa/qsinputdialogfactory.h': Permission denied ln: creating symbolic link `/usr/include/qsutilfactory.h' to `/builddir/build/BUILD/qsa-x11-opensource-1.2.1/src/qsa/qsutilfactory.h': Permission denied ln: creating symbolic link `/usr/include/qsscript.h' to `/builddir/build/BUILD/qsa-x11-opensource-1.2.1/src/qsa/qsscript.h': Permission denied ln: creating symbolic link `/usr/include/qsconfig.h' to `/builddir/build/BUILD/qsa-x11-opensource-1.2.1/src/qsa/qsconfig.h': Permission denied ln: creating symbolic link `/usr/include/qsworkbench.h' to `/builddir/build/BUILD/qsa-x11-opensource-1.2.1/src/ide/qsworkbench.h': Permission denied mv: cannot move `libqsa.so.1.2.1' to `/usr/lib/libqsa.so.1.2.1': Permission denied mv: cannot move `libqsa.so' to `/usr/lib/libqsa.so': Permission denied mv: cannot move `libqsa.so.1' to `/usr/lib/libqsa.so.1': Permission denied mv: cannot move `libqsa.so.1.2' to `/usr/lib/libqsa.so.1.2': Permission denied make[3]: [/usr/lib/libqsa.so.1.2.1] Error 1 (ignored) install: cannot stat `/usr/lib/libqsa.so.1.2.1': No such file or directory make[3]: [install_target] Error 1 (ignored)
You sure you weren't still trying to use ./configure -release -prefix %{qtdir} instead of ./configure -release ?
OK, we may have hit an rpm bug here, because despite that rpm -qlp qt4-qsa-1*.rpm returns /usr/lib/libqsa.so.1 /usr/lib/libqsa.so.1.2 After installing it, I get $ rpm -V qt4-qsa missing /usr/lib/libqsa.so.1 missing /usr/lib/libqsa.so.1.2 ??
Very interesting. Now we need someone with internal rpm knowledge. I try to find the used spec file, witch generates the buggy file.
Created attachment 138882 [details] The spec file for the problem.
I have verified, at least, that all files to get installed, *except* for libqsa.so.1.2.1 (arguably, the most important one). Clearly, the patch is insufficient as-is.
Can this bug be corrected in the fc5 branch too, please? It seems that the package for FC-5 is quite out-of-sync with FC-6 and devel.
This is not an bug of QSA. It is an Bug in the qt4 package, because the maintainer breaks the Qt rules for placing files. But he won't fix it. So there is no chance that QSA can place the files correct. The correct path file Qt files are /usr/lib/qt/lib,/usr/lib/qt/bin and /usr/lib/qt/include.
<sigh> Please, Rex and Frank, try to find an agreement on that. As is, the qt4-qsa package is broken. Just try to build an example provided in the package qt4-qsa-devel, and you will have such compile errors: main.cpp:42:23: error: qsaglobal.h: No such file or directory main.cpp:44:22: error: qseditor.h: No such file or directory The reason is that qmake-qt4 assumes that headers are in /usr/include/.
Frank and I clearly disagree here, as highlighted by his counter bug #213382 claiming this to be qt4's fault. Per my suggestion in bug #213382c#2: "Seriously, the problems with qt4-qsa are of it's own making. I'd suggest contacting upstream(1) about it, and offerring the partial patch we have as a starting point. (1) qsa-interest on http://lists.trolltech.com/ " NOTE: I've been watching the qsa-interest ml, nothing has been mentioned there about this (yet). Frank, please stop pointing fingers and engage upstream on this, especially if you're unable/unwilling to fixup the last deficiency in the patch(es) I've provided.
I have tell you many times to add symlinks to your package, to correct your path break. But until you do it I an do nothing.
Packaging files that follow symlinks is a *bad idea*. Besides, symlinks would only be a bandaid to the real problem, and wouldn't be anywhere near a proper/acceptable fix here.
For completeness, this issue was raised in the package review, see bug #191589 comment #27 in particular. Further, I had warned/threatened that qt_includedir and qt_libdir would likely change, see qt4 review (bug #188180) and bug #196901 "qt4: make FHS-friendly".
Rex and Frank, do you accept that we write mail to fedora-extras-devel, to get new opinion on that bug? Eventually, Fesco could decide. The situation seems stuck.
I'm open to the idea of further discussion and the possibility of FESCo intervention, if need. Laurent, would you mind making the post to fedora-extras to expedite things? (I'm biased/tainted). To be completely forthright, I've already discussed this with some folks at the FedoraSummit, and the consensus was that qt4-qsa really does need to be fixed.
This can be an option.
I am pleased to see that you are both accepting the idea of a mail to the list. (In reply to comment #23) > Laurent, would you mind making the post to fedora-extras > to expedite things? (I'm biased/tainted). I understand. My proposal was actually to write the mail myself. I will try to find the time to write a nice email today or tomorrow.
OK, As the person trying to work out the best way to handle this. What has upstream said on this subject?
FYI, looks like qt4-qsa will have a short lifespan, anyway: http://www.trolltech.com/products/qt/lifecyclestatement/ to be incorporated (in some form) into qt-4.3
Yes and the 1.2.2 will contains a warning about it. I hope TT will include the script engine in Qt 4.3 for all releases and not only in the commercial one.
Please make that bug fixed! QSA is actually unusable under FC-6. :-(
I'd have to say the best (short-term anyway) solution would be to do something like: fake the existence of %qtdir/lib during build, and manually move the resulting files to the proper location (%_libdir) afterward.
What about the qsa.prf file, which tells qmake how to compile with qsa?
Shouldn't qsa.prf go in %_datadir/qt4/mkspecs/features ?
Yes. But it should also be coherent with the installation. For the moment, I have a qsa.prf file which contains a line INCLUDEPATH += /usr/lib/qt4 We should make sure that this file is updated if QSA headers move to another place.
Until the Qt package is not changed no chance to fix it.
Frank i have look at this and the qt4 package is doing the right think by being FHS compliant. in turn this means the qsa also must be FHS compliant. it can be fixed with a small amount of work. Even less work if you work with upstream to make it do the right thing there? Frank as i have asked previously What does upstream say on the issue? have you engaged them at all? Fedora's moto is to work upstream and have the fixes done there and naturally flow back to us. Have you done this?
No, the first qt4 package was ok, then the maintainer of it change the place of the files and the trouble begins. So he must placed the files back to first solution, like it is done in the Qt3 package.
Frank, What was done to qt4 was advertised and is perfectly fine. qsa must meet the FHS guidelines What has upstream said about this? Have you even spoken with them?
Frank, Dennis has asked me as your sponsor to intervene here, so here I am. Frank please listen to Dennis and Rex, they are right it was decided in a 122 (?!) comment review that qt4 should not follow trolltech's broken dir layout but instead should be FHS compliant. Yes this choice causes pain for qt4-qsa and will probably also cause pain for some other packages but it is the right choice! So the next step would be to go and fix qt4-qsa. If you lack the technical autoxxx / autohell skills to fix this, then that is perfectly understandable and not a problem. Just say so and ask for help, then I or someone else can help you and fix things for you. I've taken a quick look and here is a hint: configure2/configutils.cpp is one of the big offenders here. It uses qtdir with xxx/xxx and xxx/xxx appended insstead of using things like qtinc/xxx and qtlib/xxx. That needs fixing for starters.
I can't spend time at now for an complete modify of the package. When some one has some time, then please append an fix.
That "some one" to help could be upstream. Suggestion: Ask *them*. Have I mentioned you should ask upstream? (see comment #18) Please, please? I promise to buy you a beer (or your prefered adult beverage of choice) at the next FUDCon/FUDPub. (:
The QSA mailing list is dead. I will try to find some time but that can be needed some time, because I have to do much work.
> The QSA mailing list is dead. OK, consider 1. supposedly upstream ml is dead (though I've seen quite a few posts over the past few months) 2. This pkg is broken as-is, with no time-frame for fixing 3. this will be obsoleted by qt-4.3 anyway 4. Do any existing fedora packages use qt4-qsa? would it not be wise to simply orphan this package?
Created attachment 147892 [details] PAATCH: fix qsa.pro to allow FHS compliant build (In reply to comment #42) > > The QSA mailing list is dead. > > OK, consider > 1. supposedly upstream ml is dead (though I've seen quite a few posts over the > past few months) > 2. This pkg is broken as-is, with no time-frame for fixing > 3. this will be obsoleted by qt-4.3 anyway > 4. Do any existing fedora packages use qt4-qsa? > > would it not be wise to simply orphan this package? Concedering the fact that I've put about an hour into this to write a fix this weekend, I would rather not see this orphaned :) This patch combined with the modified specfile I'm about to attach fixes this. Notice this does need testing, it compiles fine and puts everything in the right place, but thats as far as I've tested it.
Created attachment 147893 [details] spec file with mods needed together with patch to fix this All thats needed now is for you (Frank) to bump the release and write a changelog entry and then your set.
Thanks Hans, you rock.
Thanks for help, but it will fails, because the doc files are installed in teh wrong directory. Under /usr/share/qt4/ and not /usr/share/qt4-qsa.
Actually the .spec does a "rm -fr /usr/share/qt4/doc" after make install and then add then adds the docs to %doc where they belong. What is the problem here?
When I try to build the new package I will get error's about installed but not packaged files. And this one are all the doc files under /usr/share/qt4/docs/html/
<sigh>, thats why the spec file I attached contains: rm -rf $RPM_BUILD_ROOT/%{qtdata}/doc Notice doc not docS, I just tried building it (again) and it works fine.