Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 895149 (qtchooser) - Review Request: qtchooser - Qt Chooser
Summary: Review Request: qtchooser - Qt Chooser
Keywords:
Status: CLOSED ERRATA
Alias: qtchooser
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dan Mashal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: kde-reviews qt-reviews 1153827 1154372
TreeView+ depends on / blocked
 
Reported: 2013-01-14 17:22 UTC by Rex Dieter
Modified: 2014-10-19 11:07 UTC (History)
5 users (show)

Fixed In Version: qtchooser-39-1.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-06 13:34:21 UTC
dan.mashal: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Rex Dieter 2013-01-14 17:22:32 UTC
Spec URL: http://rdieter.fedorapeople.org/rpms/qt5/qtchooser.spec
SRPM URL: http://rdieter.fedorapeople.org/rpms/qt5/qtchooser-9-1.fc18.src.rpm
Description: Qt Chooser
Fedora Account System Username: rdieter

An optional addon to qt3/qt4/qt5 that arguably(1) allows easier switching between different qt development environments at runtime

(1) a matter of some debate, but this is the tool upstream came up with, so we may as well adopt and use it.

Comment 1 Kevin Kofler 2013-01-14 18:35:34 UTC
DO. NOT. WANT!

This is a horribly stupid, overengineered and useless hack. Just by a cursory glance at the specfile and the code, I can find several faults with this approach, some of which are fundamental design issues, whereas others are just a result of the implementation being a non-portable quick hack. The things I noticed:
* qtchooser installs all the qt* binaries as wrappers, but does not require any of the actual implementations, so build systems will think the executables are available when they're actually not. One could, theoretically, Require some virtual Provides, but that'd be bad in several ways: it'd be a circular dependency, it'd require all the binaries at once unless qtchooser gets split into many subpackages (ugh!) and there'd still be no guarantee that you get the version of the binary you actually wanted.
* As you already found out, this issue also breaks PackageKit-command-not-found.
* As I already explained several times, there's no sane way for a build script to reliably pick the Qt version with this system. Environment variables are not something build systems normally muck with, and the parameters are broken because they'll cause errors if the build system hits the actual binary rather than the wrapper (which it will have to be prepared for even if we ship qtchooser in Fedora, there will definitely be platforms not using it, e.g., qtchooser doesn't even support anything other than POSIX according to the comment at the beginning, even though funnily there are some #ifdef _WIN32 conditionals).
* In addition, the available Qt versions depend on config files, i.e. the build system has no way to know whether they have to pass -qt=4, -qt=4.8, -qt=4.8.3, -qt=native-4.8.3 (there have also been talks about using this for cross Qt, for which there's no standard whatsoever) etc. (or the equivalent environment variable).
* The parameter parsing is dumb lowest-level C-without-getopt-style and does not follow any POSIX, GNU or even Qt conventions.
* If $HOME is not set, the code will attempt to use a top-level /.config directory, a bug which has caused us trouble in Qt itself too. A comment in the code ("// accept empty $HOME too") tries to explain this bug into a "feature".
I'm sure there are more flaws that would become apparent if we continued further down this dead end and attempted to actually ship this junk.

I do not think we want to ship this in Fedora, ever.

Comment 2 Rex Dieter 2013-01-14 20:14:39 UTC
For anyone curious, my (1) footnote was largely for Kevin's comment #1 which I knew was coming. :)

Comment 3 Rex Dieter 2013-01-24 18:12:45 UTC
Spec URL: http://rdieter.fedorapeople.org/rpms/qt5/qtchooser.spec
SRPM URL: http://rdieter.fedorapeople.org/rpms/qt5/qtchooser-9-2.fc18.src.rpm

%changelog
* Thu Jan 24 2013 Rex Dieter <rdieter@fedoraproject.org> 9-2
- move binaries to /usr/lib/qtchooser, keeps this optional, allows
  users to install/opt-in instead

Comment 4 Kevin Kofler 2013-01-24 18:35:09 UTC
That doesn't make this thing any better. It also goes against its stated purpose (making the packaging more of a joke than anything else). And you still didn't make a case of what practical benefit this utility brings to our users.

In addition, /usr/lib is not an acceptable place for binaries, use /usr/libexec instead.

Comment 5 Kevin Kofler 2013-01-24 19:12:38 UTC
To sum up the discussion we just had on IRC:

Basically, what's the most inadequate about qtchooser is the concept that the USER should pick his Qt version, as opposed to the build system of the software he wants to build. This major design mistake shows clearly from the design, see my complaints in comment #1 about how there's no reasonable way for the build script to set the Qt version with qtchooser.

As for the proposed compromise in comment #3, the main thing I don't understand is what would be the benefit of doing:
1. Prepend /usr/lib(exec?)/qtchooser to PATH.
2. Select your Qt version in qtchooser.
over just:
1. Prepend /usr/lib/qt(version)/bin directly to PATH.
which is much simpler, does not require us to package any flawed utility, and has exactly the same effect.

Comment 6 Rex Dieter 2013-01-24 20:27:16 UTC
First off, for better or worse, fedora's policies do not require justification for a package review.  So, arguing against a package in it's review on this basis, is... pointless.

Now, *if* I were to make a case... :) I would say that qtchooser is the tool that Qt upstream came up with to standardize a way for developers to use/switch Qt development environments.  Other distros are supporting it, and I think fedora should too.  I argue not supporting qtchooser would make fedora look bad and hurt it's reputation.

Second, I do agree that better solutions than qtchooser exist, and fedora's Qt packaging already does does support (imo) better options, like manually adjusting paths or using -qt4 and/or -qt5 postfix on related binaries as mentioned.  However, that does not preclude supporting *yet another option*.  This latest packaging implementation is careful to minimize side-effects, is not installed or used by default, and is strictly optional.

As for binary location, I personally don't care all that much (/usr/lib/bikeshed anyone?).  Strictly, our guidelines allow either, and I only chose /usr/lib (similar to ccache) because I personally consider /usr/libexec to be non-user-facing.  I don't consider either option *wrong*.

Comment 7 Kevin Kofler 2013-01-24 21:12:20 UTC
> First off, for better or worse, fedora's policies do not require justification
> for a package review.  So, arguing against a package in it's review on this
> basis, is... pointless.

Packaging a package that serves no purpose is what is pointless.

> Now, *if* I were to make a case... :) I would say that qtchooser is the tool
> that Qt upstream came up with to standardize a way for developers to use/switch
> Qt development environments.  Other distros are supporting it, and I think
> fedora should too.  I argue not supporting qtchooser would make fedora look bad
> and hurt it's reputation.

And I argue that "supporting" this half-assed solution in an even more half-assed way (your "compromise" which "fixes" the blocking issues by just requiring a manual step to enable qtchooser, which makes it even more pointless because the same method can be used to just choose Qt directly) is what will make Fedora look bad and hurt its reputation.

We need instead to make a clear stand that qtchooser is NOT a suitable solution for the problem it is designed to solve and that a better solution needs to be standardized across distros. (And if the other distros refuse, that's their loss. Chances are at least RHEL will follow us. E.g., RHEL 6 ships my kdelibs parallel-devel setup unchanged.)

> Second, I do agree that better solutions than qtchooser exist, and fedora's Qt
> packaging already does does support (imo) better options, like manually
> adjusting paths or using -qt4 and/or -qt5 postfix on related binaries as
> mentioned.

That's exactly why qtchooser is useless.

> However, that does not preclude supporting *yet another option*.

But it makes it pointless.

> This latest packaging implementation is careful to minimize side-effects, is
> not installed or used by default, and is strictly optional.

And as a result, it solves no problem at all.

> As for binary location, I personally don't care all that much
> (/usr/lib/bikeshed anyone?).  Strictly, our guidelines allow either, and I only
> chose /usr/lib (similar to ccache) because I personally consider /usr/libexec
> to be non-user-facing.  I don't consider either option *wrong*.

The fact that binaries are allowed in /usr/lib is an unfortunate loophole in our guidelines. This is clearly what libexec is for.

Comment 8 Dan Mashal 2013-07-28 13:58:05 UTC
APPROVED. Looks fine here. Tested, and installed properly on a rawhide box. 

I will leave it up to Rex's good and proven judgement as to why this package should be in Fedora. 

Rex, please review the shoulds. 

Licensing looks OK.

Go on.





Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed


Issues:
=======
- Sources used to build the package match the upstream source, as provided in
  the spec URL.
  Note: Check did not completechecksum differs and there are problems running
  diff. Please verify manually.
  See: http://fedoraproject.org/wiki/Packaging/SourceURL


===== MUST items =====

C/C++:
[ ]: Package does not contain kernel modules.
[ ]: Package contains no static executables.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

Generic:
[ ]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[ ]: %build honors applicable compiler flags or justifies otherwise.
[ ]: Package contains no bundled libraries without FPC exception.
[ ]: Changelog in prescribed format.
[ ]: Sources contain only permissible code or content.
[ ]: Package contains desktop file if it is a GUI application.
[ ]: Development files must be in a -devel package
[ ]: Package requires other packages for directories it uses.
[ ]: Package uses nothing in %doc for runtime.
[ ]: Package is not known to require ExcludeArch.
[ ]: Package complies to the Packaging Guidelines
[ ]: If (and only if) the source package includes the text of the license(s)
     in its own file, then that file, containing the text of the license(s)
     for the package is included in %doc.
[ ]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses found:
     "Unknown or generated". 2 files have unknown license. Detailed output of
     licensecheck in /home/dan/895149-qtchooser/licensecheck.txt
[ ]: Package consistently uses macro is (instead of hard-coded directory
     names).
[ ]: If the package is under multiple licenses, the licensing breakdown must
     be documented in the spec.
[ ]: Package is named according to the Package Naming Guidelines.
[ ]: Package does not generate any conflict.
[ ]: Package obeys FHS, except libexecdir and /usr/target.
[ ]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[ ]: Package must own all directories that it creates.
[ ]: Package does not own files or directories owned by other packages.
[ ]: Requires correct, justified where necessary.
[ ]: Spec file is legible and written in American English.
[ ]: Package contains systemd file(s) if in need.
[x]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Each %files section contains %defattr if rpm < 4.4
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Fully versioned dependency in subpackages, if present.
[x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package do not use a name that already exist
[x]: Package is not relocatable.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Large documentation must go in a -doc subpackage.
     Note: Documentation size is 0 bytes in 0 files.
[x]: Packages must not store files under /srv, /opt or /usr/local
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: No rpmlint messages.

===== SHOULD items =====

Generic:
[!]: Spec use %global instead of %define.
     Note: %define git g980c64c
[ ]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.
[ ]: Final provides and requires are sane (see attachments).
[ ]: Package functions as described.
[ ]: Latest version is packaged.
[ ]: Package does not include license text files separate from upstream.
[ ]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[ ]: Package should compile and build into binary rpms on all supported
     architectures.
[ ]: %check is present and all tests pass.
[ ]: Packages should try to preserve timestamps of original installed files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: Dist tag is present.
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Uses parallel make.
[x]: SourceX tarball generation or download is documented.
[x]: SourceX is a working URL.

===== EXTRA items =====

Generic:
[!]: Spec file according to URL is the same as in SRPM.
     Note: Spec file as given by url is not the same as in SRPM (see attached
     diff).
[x]: Large data in /usr/share should live in a noarch subpackage if package is
     arched.
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).


Rpmlint
-------
Checking: 
0 packages and 0 specfiles checked; 0 errors, 0 warnings.




Rpmlint (installed packages)
----------------------------
Cannot parse rpmlint output:


Diff spec file in url and in SRPM
---------------------------------
--- /home/dan/895149-qtchooser/srpm/qtchooser.spec	2013-07-28 06:48:59.901201161 -0700
+++ /home/dan/895149-qtchooser/srpm-unpacked/qtchooser.spec	2013-07-28 06:49:01.758243319 -0700
@@ -1,9 +1,9 @@
 
-%define git g980c64c 
+%define git g8f08405
 
 Name:	 qtchooser
 Summary: Qt Chooser
-Version: 31
-Release: 1%{?dist}
+Version: 9
+Release: 2%{?dist}
 
 License: LGPLv2 or GPLv3
@@ -47,9 +47,8 @@
 mkdir -p %{buildroot}%{_sysconfdir}/profile.d
 install -m644 -p %{SOURCE10} %{SOURCE11} \
-  %{buildroot}%{_sysconfdir}/profile.d/
+  %{buildroot}%{_sysconfdir}/profile.d
 
 
 %files
-%doc LGPL_EXCEPTION.txt LICENSE.GPL LICENSE.LGPL
 %dir %{_sysconfdir}/xdg/qtchooser
 %{_sysconfdir}/profile.d/qtchooser.*
@@ -68,6 +67,4 @@
 %{_prefix}/lib/qtchooser/qdbusviewer
 %{_prefix}/lib/qtchooser/qdbusxml2cpp
-%{_prefix}/lib/qtchooser/qdoc
-%{_prefix}/lib/qtchooser/qdoc3
 %{_prefix}/lib/qtchooser/qglinfo
 %{_prefix}/lib/qtchooser/qhelpconverter
@@ -91,10 +88,4 @@
 
 %changelog
-* Sat May 18 2013 Rex Dieter <rdieter@fedoraproject.org> 31-1
-- qtchooser-31
-
-* Wed Mar 06 2013 Rex Dieter <rdieter@fedoraproject.org> 26-1
-- qtchooser-26
-
 * Thu Jan 24 2013 Rex Dieter <rdieter@fedoraproject.org> 9-2
 - move binaries to /usr/lib/qtchooser, keeps this optional, allows


Requires
--------


Provides
--------


Source checksums
----------------
http://macieira.org/qtchooser/qtchooser-31-g980c64c.tar.gz :
  CHECKSUM(SHA256) this package     : ERROR
  CHECKSUM(SHA256) upstream package : b50acc2140aec58081b82e6df136251596dec7c5d3bf1f95c0ff650fa346d5cf


Generated by fedora-review 0.4.1 (b2e211f) last change: 2013-04-29
Buildroot used: fedora-19-x86_64
Command line :/bin/fedora-review -b 895149

Comment 9 Rex Dieter 2013-07-30 16:00:23 UTC
New Package SCM Request
=======================
Package Name: qtchooser
Short Description: Qt Chooser
Owners: than rdieter jreznik kkofler ltinkl rnovacek
Branches: f18 f19
InitialCC:

Comment 10 Gwyn Ciesla 2013-07-30 17:34:58 UTC
Git done (by process-git-requests).

Comment 11 Rex Dieter 2013-08-06 13:34:21 UTC
imported

Comment 12 Fedora Update System 2014-01-13 18:40:50 UTC
qtchooser-39-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/qtchooser-39-1.fc19

Comment 13 Fedora Update System 2014-01-24 07:41:44 UTC
qtchooser-39-1.fc19 has been pushed to the Fedora 19 stable repository.


Note You need to log in before you can comment on or make changes to this bug.