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

Fri Jul 22 12:50:39 CEST 2011

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.
+
+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:
+- 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)?
+
+- 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
+  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...
+
+WDYT?
+
+-- 
+Ahmad Samir
+