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

Fri Jul 22 13:39:00 CEST 2011

On 22 July 2011 13:24, Christiaan Welvaart <cjw at daneel.dyndns.org> 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
+