This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 490132 - (mingw32-qt) Review Request: mingw32-qt - Qt library for MinGW
Review Request: mingw32-qt - Qt library for MinGW
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Richard W.M. Jones
Fedora Extras Quality Assurance
:
Depends On: mingw32-gcc mingw32-qt-qmake
Blocks: mingw32-qwt
  Show dependency treegraph
 
Reported: 2009-03-13 09:47 EDT by Thomas Sailer
Modified: 2009-03-15 23:12 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-15 23:12:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
rjones: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Thomas Sailer 2009-03-13 09:47:49 EDT
Spec URL: http://sailer.fedorapeople.org/mingw32-qt.spec
SRPM URL: http://sailer.fedorapeople.org/mingw32-qt-4.5.0-2.fc11.src.rpm
Description:
MinGW Qt library.

Approved MinGW packaging guidelines are here:
http://fedoraproject.org/wiki/Packaging/MinGW

See also the discussion on the mingw mailing list:
http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-March/000798.html
Comment 1 Kevin Kofler 2009-03-13 11:13:28 EDT
> #BuildRequires:  qt-devel = %{version}  Stupid, can't write this ...

Use:
BuildRequires: qt4-devel = %{version}

Otherwise, you'd have to add the Epoch, i.e.:
BuildRequires: qt-devel = 1:%{version}
Comment 2 Richard W.M. Jones 2009-03-13 11:22:39 EDT
(In reply to comment #1)
> > #BuildRequires:  qt-devel = %{version}  Stupid, can't write this ...
> 
> Use:
> BuildRequires: qt4-devel = %{version}
> 
> Otherwise, you'd have to add the Epoch, i.e.:
> BuildRequires: qt-devel = 1:%{version}  

No the problem is we want to buildrequire the same version
of Fedora's native Qt package, but any release.  The reason
is that we want to use the natively compiled 'moc' program.
However 'moc' only works with a matching version of Qt
(eg. all Qt 4.5.0 or whatever).

Now we cannot BuildRequire a specific version-release of
qt-devel (or qt4-devel) because this comes from a different
package, so we would constantly have to chase the native
Fedora package every time they did a new release.

What we want to do is to BR "%{version}-*", but AFAIK there
is no way to do this in RPM.

$ rpm -q --provides qt-devel | grep qt4-devel
qt4-devel = 4.4.3-10.fc10
Comment 3 Richard W.M. Jones 2009-03-13 11:24:16 EDT
One way to solve this would be if the qt-devel package
could add an explicit provides, like:

Provides: qt(api) = 4.5.0
Comment 4 Kevin Kofler 2009-03-13 11:38:28 EDT
= %{version} does exactly that, it matches the version no matter what the %{release} is. The reason it did not work for you is because of the Epoch.
Comment 5 Richard W.M. Jones 2009-03-13 12:35:07 EDT
Thanks Kevin, I didn't realize that.

Taking for review.
Comment 6 Richard W.M. Jones 2009-03-13 12:37:38 EDT
Probably a good idea to add:

Obsoletes: mingw32-qt-win <= 4.5.0
Provides: mingw32-qt-win = %{version}

otherwise people who are upgrading from the temporary
repository will get conflicts.
Comment 7 Richard W.M. Jones 2009-03-13 13:09:59 EDT
Ouch this takes a long time to compile :-(

auto-buildrequires suggests that you have all the right
BuildRequires lines.

rpmlint says:

mingw32-qt.src:219: W: libdir-macro-in-noarch-package %{_libdir}/qt4/mkspecs/fedora-win32-cross

This seems OK ...

mingw32-qt.src: W: strange-permission qt-win-configure.sh 0775

Fine, rpmlint shouldn't complain about these.

mingw32-qt.noarch: E: devel-dependency qt-devel

This is OK, because mingw32-qt is really a devel package.
However, see comment 1.

mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtSql4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libqtmaind.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtGuid4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQt3Support4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtXmld4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtSvgd4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtXml4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtSqld4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtCore4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtNetwork4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtSvg4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libqtmain.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQt3Supportd4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtNetworkd4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtCored4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtGui4.a

You can ignore these, see:
http://fedoraproject.org/wiki/MinGW/Rpmlint#arch-independent-package-contains-binary-or-object

mingw32-qt.noarch: E: only-non-binary-in-usr-lib

This refers to the following files:

/usr/lib64/qt4/mkspecs/fedora-win32-cross/qmake.conf
/usr/lib64/qt4/mkspecs/fedora-win32-cross/qplatformdefs.h

and that seems OK.
Comment 8 Richard W.M. Jones 2009-03-13 13:12:02 EDT
Koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1240262
Comment 9 Richard W.M. Jones 2009-03-13 13:20:13 EDT
+ rpmlint output
+ package name satisfies the packaging naming guidelines
+ specfile name matches the package base name
+ package should satisfy packaging guidelines
+ license meets guidelines and is acceptable to Fedora
+ license matches the actual package license
+ %doc includes license file
+ spec file written in American English
+ spec file is legible
+ upstream sources match sources in the srpm
+ package successfully builds on at least one architecture
  i586 and x86_64
n/a ExcludeArch bugs filed
+ BuildRequires list all build dependencies
n/a %find_lang instead of %{_datadir}/locale/*
n/a binary RPM with shared library files must call ldconfig in %post and %postun
+ does not use Prefix: /usr
+ package owns all directories it creates
+ no duplicate files in %files
+ %defattr line
+ %clean contains rm -rf $RPM_BUILD_ROOT
+ consistent use of macros
+ package must contain code or permissible content
n/a large documentation files should go in -doc subpackage
+ files marked %doc should not affect package
n/a header files should be in -devel
  ok for mingw packages to have headers
n/a static libraries should be in -static
n/a packages containing pkgconfig (.pc) files need 'Requires: pkgconfig'
n/a libfoo.so must go in -devel
n/a -devel must require the fully versioned base
n/a packages should not contain libtool .la files
n/a packages containing GUI apps must include %{name}.desktop file
+ packages must not own files or directories owned by other packages
+ %install must start with rm -rf %{buildroot} etc.
+ filenames must be valid UTF-8

Optional:

n/a if there is no license file, packager should query upstream
n/a translations of description and summary for non-English languages, if available
+ reviewer should build the package in mock
? the package should build into binary RPMs on all supported architectures
+ review should test the package functions as described
n/a scriptlets should be sane
n/a pkgconfig files should go in -devel
n/a shouldn't have file dependencies outside /etc /bin /sbin /usr/bin or /usr/sbin

-----------------------

This package is APPROVED by rjones

-----------------------
Comment 10 Richard W.M. Jones 2009-03-13 13:21:23 EDT
Please see comment 1 and comment 6 before committing.
Comment 11 Kevin Kofler 2009-03-13 13:23:46 EDT
> mingw32-qt.src:219: W: libdir-macro-in-noarch-package
> %{_libdir}/qt4/mkspecs/fedora-win32-cross
>
> This seems OK ...

No, it's not. Noarch packages MUST NOT install to %{_libdir} as that expands to something different depending on the arch it's built on. In addition, 64-bit qmake will not find the mkspecs in /usr/lib, so even hardcoding it as /usr/lib is wrong.

We used /usr/share/qt4/mkspecs in the native Qt at some point, but this was changed because it causes other problems. So unless we can get the native Qt to look there as well, this package cannot be noarch.
Comment 12 Richard W.M. Jones 2009-03-13 13:55:03 EDT
What was the problem that stopped Qt using /usr/share?
It sounds like a bug in the base Qt package TBH.
Comment 13 Richard W.M. Jones 2009-03-13 13:59:16 EDT
Actually for now I think we should split the
qmake specs into a separate package.  mingw32-qt.noarch
will have to depend on this.  This new package will be
arch-specific, but will only contain a couple of files,
so quick to build.
Comment 14 Thomas Sailer 2009-03-13 14:24:56 EDT
New Package CVS Request
=======================
Package Name: mingw32-qt
Short Description: Qt for MinGW32
Owners: sailer rjones
Branches: 
InitialCC:
Comment 15 Thomas Sailer 2009-03-13 14:25:57 EDT
Thanks for the quick review! I agree, let's split out the qmake related files into a separate package named mingw32-qt-qmake. I will do that and file a separate review for this mingw32-qt-qmake package.
Comment 16 Levente Farkas 2009-03-13 15:31:38 EDT
as for #6 should we have to care about temp repos?
Comment 17 Kevin Kofler 2009-03-13 15:33:39 EDT
IMHO: yes, definitely, especially in a case like this where a simple Obsoletes/Provides is all it takes.
Comment 18 Richard W.M. Jones 2009-03-13 15:36:48 EDT
Yes, I agree with Kevin.  It costs almost nothing to add this,
and makes the experience better for quite a lot of early
adopters.  There are many hundreds of silent people using
the temporary yum repository.
Comment 19 Kevin Fenzi 2009-03-15 22:02:37 EDT
cvs done.
Comment 20 Thomas Sailer 2009-03-15 23:12:08 EDT
Reviewer comments implemented, and built for rawhide.

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