1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] RFC: gtk-doc proposed changes
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20RFC%3A%20gtk-doc%20proposed%20changes&In-Reply-To=%3Calpine.LMD.2.02.1107221301560.23690%40zem.cjw.nep%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="006961.html">
<LINK REL="Next" HREF="006963.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] RFC: gtk-doc proposed changes</H1>
<B>Christiaan Welvaart</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20RFC%3A%20gtk-doc%20proposed%20changes&In-Reply-To=%3Calpine.LMD.2.02.1107221301560.23690%40zem.cjw.nep%3E"
TITLE="[Mageia-dev] RFC: gtk-doc proposed changes">cjw at daneel.dyndns.org
</A><BR>
<I>Fri Jul 22 13:24:27 CEST 2011</I>
<P><UL>
<LI>Previous message: <A HREF="006961.html">[Mageia-dev] RFC: gtk-doc proposed changes
</A></li>
<LI>Next message: <A HREF="006963.html">[Mageia-dev] RFC: gtk-doc proposed changes
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#6962">[ date ]</a>
<a href="thread.html#6962">[ thread ]</a>
<a href="subject.html#6962">[ subject ]</a>
<a href="author.html#6962">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>On Fri, 22 Jul 2011, Ahmad Samir wrote:
><i> ATM gtk-doc requires dblatex which requires texlive -> texlive-texmf;
</I>><i> due to the outrageous size of texlive-texmf, building packages in
</I>><i> local chroots becomes a bit of pain/burden on my HDD, also each of
</I>><i> texlive and xmltex have I/O intensive postinstall scriptlets.
</I>
The best solution for that may be to put the chroot in a tmpfs.
><i> I see the texlive-texmf issue is being discussed in another thread so
</I>><i> I'll keep this one about gtk-doc; here're a couple of points:
</I>
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.
><i> - Some packages have BR gtk-doc but it's redundant:
</I>><i> o They don't have --enable-gtk-doc passed to ./configure, which
</I>><i> means that BR isn't used at all
</I>><i> o Most of those packages already bundle html gtk-doc's; is there any
</I>><i> benefit rebuilding those docs when building the package? or should the
</I>><i> gtk-doc BR get dropped in such cases (since no one complained about
</I>><i> those html docs all those years)?
</I>
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> - I am thinking of splitting gtk-doc itself, putting gtkdoc-mkpdf in a
</I>><i> separate sub-package which will require dblatex:
</I>><i> o AFAICS dblatex is only used for creating PDF's from XML sources,
</I>><i> so only useful for gtkdoc-mkpdf
</I>
Interesting.
><i> o This will result in less HDD grinding due to texlive-texmf and
</I>><i> xmltex being, unnecessarily, pulled in chroots (either local ones or
</I>><i> on the BS). Note that for most of the packages I saw,
</I>><i> --enable-gtk-doc-html is the default (assuming only --enable-gtk-doc
</I>><i> was passed to configure).
</I>><i> o I don't see any packages with pdf gtk-doc documentation:
</I>><i> $ urpmf /usr/share/gtk-doc | grep pdf
</I>><i>
</I>><i> gives nothing at all.
</I>><i>
</I>><i> So, theoretically, this split shouldn't break any packages (there're
</I>><i> 144 SRPMS that have BR gtk-doc and 5 -devel packages that require
</I>><i> gtk-doc). And if any package breaks due to the split, the fix is
</I>><i> simply adding BR gtk-doc-pdf. Of course we can make it more painful
</I>><i> and require that those 149 packages get a test build before the split
</I>><i> is OK'ed...
</I>
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 (:
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="006961.html">[Mageia-dev] RFC: gtk-doc proposed changes
</A></li>
<LI>Next message: <A HREF="006963.html">[Mageia-dev] RFC: gtk-doc proposed changes
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#6962">[ date ]</a>
<a href="thread.html#6962">[ thread ]</a>
<a href="subject.html#6962">[ subject ]</a>
<a href="author.html#6962">[ author ]</a>
</LI>
</UL>
<hr>
<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev
mailing list</a><br>
</body></html>
|
