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