Thanks for trying this out and showing that it can be done, but I do not agree with this approach at all.

From a user perspective, even if you want to build qt5-doc from a single SRPM, you still have to split it into subpackages, possibly with a metapackage that requires them all. What's the point of splitting qt5-* including -devel if -doc is monolithic?

And doing things this way is an issue for QtWebEngine because QtWebEngine can be upgraded without the rest of Qt (as has been done for 5.8), and so the docs in this monolithic package (or even in a subpackage of it if you introduce them) will not match the actual package. Therefore, in my role of the QtWebEngine maintainer, I explicitly disapprove the Obsoletes on qt5-qtwebengine-doc.

(And as I wrote on IRC, I also disagree with this approach on technical grounds, because you are no longer building the documentation from source in the specfile, it has to be manually prepared (in a process that takes hours) before even generating the SRPM.)

I can review this

re: comment #1

I agree with Kevin in general.

1. Ideally we'll want to create a bunch of subpkgs + umbrella metapackage instead of this initial monolithic approach.  That said, I won't consider that a review blocker, and we can implement that after import.

2. In the case of qtwebengine, when/if we have to, we can omit its docs from here as needed.

The split can be done now, but then will end up in subpackages that will be broken as well.

To mention, for example, let's say that i will install qt5-doc-qtdeclarative, and inside it we have links for doc from qtbase, qtxmlpatterns, etc, etc..
So we will need to require this packages on the subpackage.

Unless we create a script to parse all documentation to discover all the requires, this will be very difficult to track.

The solution of have the parent meta package solve this, but then, if someone decide to install one single module, we will end up in the same situation as before.

I can't understand why this is a big deal, because i don't see anyone complaining on old package qt4 doc that is big and monolithic as well.

The whole Qt 4 was monolithic, so of course the -doc package was, too.

And I don't see the big deal if a link to, e.g., QtCore is broken if you don't have QtCore docs installed, that's IMHO completely expected.

Updated with splitted individual packages

Spec URL: http://copr-dist-git.fedorainfracloud.org/cgit/@kdesig/qt-5.9/qt5-doc.git/tree/qt5-doc.spec

SRPM URL: https://copr-be.cloud.fedoraproject.org/results/%40kdesig/qt-5.9/fedora-rawhide-x86_64/00549587-qt5-doc/qt5-doc-5.9.0-0.beta.3.fc27.src.rpm

Thanks.
Release: 
Naming: ok

License: ok

Sources: ok (generating script included).

macros: ok
1.  SHOULD use %{_qt5_docdir} instead of %{_docdir} macro, ie, replace %{_docdir}/qt5/ references with just:  %{_qt5_docdir}

2.  subpackage deps SHOULD use full version-release, like:
Requires: qt5-qtbase-doc = %{version}-%{release}

scriplets: n/a

3.  SHOULD use proper Release tag, something like
Release: 0.3.beta3%{?dist}
instead of existing
Release: 0.beta.3%{?dist}
style

I won't consider these blockers, and can easily be fixed after import.


APPROVED

Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/rpms/qt5-doc

This was imported long ago, closing