[Mageia-dev] RFC: gtk-doc proposed changes

Fri Jul 22 13:24:27 CEST 2011

On Fri, 22 Jul 2011, Ahmad Samir wrote:
+
+> ATM gtk-doc requires dblatex which requires texlive -> texlive-texmf;
+> due to the outrageous size of texlive-texmf, building packages in
+> local chroots becomes a bit of pain/burden on my HDD, also each of
+> texlive and xmltex have I/O intensive postinstall scriptlets.
+
+The best solution for that may be to put the chroot in a tmpfs.
+
+> I see the texlive-texmf issue is being discussed in another thread so
+> I'll keep this one about gtk-doc; here're a couple of points:
+
+Too bad since this appears to be strongly related to the gtk-doc issue you 
+mention. I mean, providing a minimal set of texlive packages may fix this 
+gtk-doc problem.
+
+> - Some packages have BR gtk-doc but it's redundant:
+>  o They don't have --enable-gtk-doc passed to ./configure, which
+> means that BR isn't used at all
+>  o Most of those packages already bundle html gtk-doc's; is there any
+> benefit rebuilding those docs when building the package? or should the
+> gtk-doc BR get dropped in such cases (since no one complained about
+> those html docs all those years)?
+
+In general I think it's best to generate everything from original sources 
+[1]. It makes sure all build scripts/code/documentation is generated using 
+the tools in the distro which may be newer and/or have patches compared to 
+the tools used to generate the files shipped with the source code. It also 
+ensures we can support such packages, because when someone reports a bug 
+in a generated file we should never patch that file directly but its 
+source.
+
+> - I am thinking of splitting gtk-doc itself, putting gtkdoc-mkpdf in a
+> separate sub-package which will require dblatex:
+>  o AFAICS dblatex is only used for creating PDF's from XML sources,
+> so only useful for gtkdoc-mkpdf
+
+Interesting.
+
+>  o This will result in less HDD grinding due to texlive-texmf and
+> xmltex being, unnecessarily, pulled in chroots (either local ones or
+> on the BS). Note that for most of the packages I saw,
+> --enable-gtk-doc-html is the default (assuming only --enable-gtk-doc
+> was passed to configure).
+>  o I don't see any packages with pdf gtk-doc documentation:
+>  $ urpmf /usr/share/gtk-doc | grep pdf
+>
+>  gives nothing at all.
+>
+> So, theoretically, this split shouldn't break any packages (there're
+> 144 SRPMS that have BR gtk-doc and 5 -devel packages that require
+> gtk-doc). And if any package breaks due to the split, the fix is
+> simply adding BR gtk-doc-pdf. Of course we can make it more painful
+> and require that those 149 packages get a test build before the split
+> is OK'ed...
+
+Maybe we should first set as policy to provide HTML developer 
+documentation and not PDFs when there is a choice. Note however that HTML 
+docs generated by doxygen can take a lot of space.
+
+
+
+     Christiaan
+
+
+[1] that's why I'd like to ask you not to remove any autoreconf/autotools/etc. 
+calls from %build (:
+
+