The root-doc package is almost 700MB in size, and has over 20000 files. I noticed that the documentation is generated by root after the build. Could that be changed to being generated in %post by root-doc? Would the necessary files be available on the user's hard drive? I'm thinking something like this (disclaimer: I don't know root and I haven't actually tested it): root-doc has one file: /usr/libexec/root-generate-docs which would look something like: #/bin/sh cd /usr/share/doc/root-doc/html /bin/root.exe -l -b -q html.C All root packages have the following in %post: if [ -e /usr/libexec/root-generate-docs ]; then /usr/libexec/root-generate-docs fi The advantage of this method is that the user no longer has to download 700MB for documentation, and the documentation automatically gets updated whenever the user adds a new root-* subpackage. It also means that the 20000 files are no longer listed in filelists.xml, which means a smaller download for all users. The downside is that documentation generation will cost the user time, but that can be traded off against the time it would normally take for the user to download the documentation.
(In reply to comment #0) > The downside is that documentation generation will cost the user time, but that > can be traded off against the time it would normally take for the user to > download the documentation. Please make it completely optional instead, so a user can choose to not have docs! If you want to make it in %post, pleast only in the %post of the root-doc subpackage, so there is no need to generate docs, when simply installing the main package (without wanting docs).
Um, that's how it would work above. root-generate-docs is only available in root-doc, so if root-doc isn't installed, no docs will be generated. The reason you'd want it in all the package's %post is that *if* you've installed root-doc, it's assumed you'd want the docs for any root packages installed later.
No, building packages/content client side defeats the purpose of a package managed system such as Fedora (put another way, Fedora is not Gentoo), and in the general case would add extra Requires to -doc packages (to pull in the tools to build the docs). This is not the right way to solve the problem.
While I agree with you in the general case, I believe this package is an exception. The size of the download means that the total time spent generating the client side docs is less than download time for all but the fastest (3mbit/s+) internet connections. I did test this and I am able to generate most (but not all, I seem to be missing some of the src/ directory) of the documentation after installing all of root-* except root-doc. The total time on my laptop was 37 minutes. Mattias, if you're not interested in generating the docs client-side, please at least consider removing the src documentation (it makes up 1/3 of the final package size).
Would it work to install a zip file of the documentation and let the user read it via gvfs-archive or some similar tool?
You need to also think of slow computers. My Pentium 4 Northwood is not going to be as fast at generating the files than a Core i7. And a Pentium Pro (the oldest CPU we support) is going to be a lot slower than even my P4. As for the Internet connection: I've downloaded root-doc in 4 minutes, at 2.5 megaBYTES per second. And that's in Vienna, Austria. There are places with even faster Internet connections. Not everyone has slow Internet and a fast CPU. In my case, it'd take 20+ times as long to build the documentation on the client than to download it! Plus, there's also other technical issues, e.g. that the files generated that way bypass RPM's file ownership concept. Scriptlets should really ONLY be used when it is IMPOSSIBLE to package the files in another way. (See also how dropping files into a someconfig.d is preferred to scriptlets tweaking someconfig.) Fedora is NOT a source-based distribution. Whatever can be generated on the build system MUST be generated on the build system, not on the client. In addition, generating the documentation on the client means you need to install the source code (!) of the package on the client. This is in itself a significant download and it's also something Fedora does not normally do. In short, %post is DEFINITELY NOT the right way to handle this.
And by the way, nobody forces the user to download the -doc subpackage, that's why it's a subpackage.
The documentation is generated from the sources, not from the installed files. It is similar to doxygen - the root HTML module reads special mark-up in the sources. We don't run doxygen in %post either. All files needed for the generation of the documentation are not available in the installation. Installing the -doc package is optional - nothing depends on it. If you don't need it you don't have to install it. The tutorial and test suite files have been split off to a separate -tutorial package, so the -doc contains only the html now. It is no longer necessary to install the -doc package if all you need is the tutorial or test suite files. ( The push of the update got screwed up though - bodhi says it was pushed, but the wrong version got tagged in koji somehow. I filed i rel-eng ticket about it but noone has acted upon it yet: https://fedorahosted.org/rel-eng/ticket/3927 ) If you think the -doc package is too big - just don't install it.
There is still the alleged 200KB bloat of filelists.xml.gz .
Mattias, I totally understand if you don't want to generate the documentation client-side. It was merely a suggestion on my part to try to reduce the size of the rpm (and, more importantly, the number of files in the rpm). I would ask that you consider removing the source documentation, unless it is useful when programming in root. As mentioned in Comment 4, it alone makes up a third of the package.
Kevin, I find it incredibly rude of you to close a bug that's not assigned to you and that you didn't report. I understand that you have strong feelings about this, but you are not the sole arbitrator of what Fedora is. If Mattias wants to close this as NOTABUG, that's his right. Please allow *him* to exercise it.
It is a plain triaging task to close a clearly invalid request as NOTABUG. And the maintainer confirmed in comment #8 that there is no bug. I find it incredibly rude to reopen a closed bug without a valid reason to reopen it.
I was quite happy having this bug closed.