On 22 July 2011 13:24, Christiaan Welvaart <[email protected]> wrote: > 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.
That policy has been implicitly in effect for a very long time, I couldn't find a single gtk-doc pdf.... > Note however that HTML docs generated > by doxygen can take a lot of space. > Yes; but that's a different issue, texlive* takes a lot of time to install but builds pdf's fast; doxygen is vice versa, installs quickly but takes a long time to build the docs sometimes... > > > Christiaan > > > [1] that's why I'd like to ask you not to remove any > autoreconf/autotools/etc. calls from %build (: > > You're talking about gnome-control-center? I thought autoreconf was run by mistake, as the old comment said it must be run for patch19 which hasn't applied for some time. But indeed, there should be a clear policy about that: either we execute autoreconf/autotool.. etc for all packages (make %configure2_5x run it or something), or we only run it when needed for e.g. a patch or a package that has an old/new libtool than our libtool.... -- Ahmad Samir
