Gentoo Archives: gentoo-doc-cvs

From: Stefano Rossi <so@×××××××××××.org>
To: gentoo-doc-cvs@l.g.o
Subject: [gentoo-doc-cvs] cvs commit: kde-split-ebuilds.xml
Date: Sun, 30 Oct 2005 18:26:27
Message-Id: 200510301826.j9UIQJ48027058@robin.gentoo.org
1 so 05/10/30 18:26:17
2
3 Modified: xml/htdocs/doc/en kde-split-ebuilds.xml
4 Log:
5 #110460 updated KDE split ebuilds
6
7 Revision Changes Path
8 1.8 +61 -65 xml/htdocs/doc/en/kde-split-ebuilds.xml
9
10 file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/kde-split-ebuilds.xml?rev=1.8&content-type=text/x-cvsweb-markup&cvsroot=gentoo
11 plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/kde-split-ebuilds.xml?rev=1.8&content-type=text/plain&cvsroot=gentoo
12 diff : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/kde-split-ebuilds.xml.diff?r1=1.7&r2=1.8&cvsroot=gentoo
13
14 Index: kde-split-ebuilds.xml
15 ===================================================================
16 RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/en/kde-split-ebuilds.xml,v
17 retrieving revision 1.7
18 retrieving revision 1.8
19 diff -u -r1.7 -r1.8
20 --- kde-split-ebuilds.xml 9 Sep 2005 07:26:39 -0000 1.7
21 +++ kde-split-ebuilds.xml 30 Oct 2005 18:26:17 -0000 1.8
22 @@ -1,6 +1,6 @@
23 <?xml version='1.0' encoding='UTF-8'?>
24
25 -<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/kde-split-ebuilds.xml,v 1.7 2005/09/09 07:26:39 fox2mike Exp $ -->
26 +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/kde-split-ebuilds.xml,v 1.8 2005/10/30 18:26:17 so Exp $ -->
27
28 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
29
30 @@ -22,8 +22,8 @@
31 <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
32 <license/>
33
34 -<version>1.5</version>
35 -<date>2005-07-02</date>
36 +<version>1.6</version>
37 +<date>2005-10-30</date>
38
39 <chapter>
40 <title>The Split KDE Ebuilds</title>
41 @@ -32,20 +32,21 @@
42 <body>
43
44 <p>
45 -Until January 2005, the only KDE ebuilds in Portage were 'monolithic' ones. That
46 -is to say, there were only 15 ebuilds, and each one installed many applications
47 -that did not, in fact, depend on one another. This was clearly a suboptimal
48 -situation, and not very Gentoo-ish, but it was tolerated for a long time.
49 +Until January 2005, the only KDE ebuilds in Portage were 'monolithic' ones.
50 +That is to say, there were only 15 ebuilds (kdebase, kdenetwork, ...), and
51 +each one installed many applications that did not, in fact, depend on one
52 +another. This was clearly a suboptimal situation, and not very Gentoo-ish,
53 +but it was tolerated for a long time.
54 </p>
55
56 <p>
57 -The new 'split' ebuilds rectified the situation by providing separate ebuilds
58 -for all the separate KDE applications. This gave us a grand total of about 330
59 -new ebuilds in the kde-base category.
60 +The new 'split' ebuilds (for konqueror, kmail, ...) rectified the situation by
61 +providing separate ebuilds for all the separate KDE applications. This gave us
62 +a grand total of about 330 new ebuilds in the kde-base category.
63 </p>
64
65 <p>
66 -We still provide monolithic ebuilds for KDE 3.4 and they are cleanly
67 +We still provide monolithic ebuilds for KDE 3.4 and 3.5 and they are cleanly
68 interoperable with the split ones. However, the split ebuilds are the new
69 default, and there will be no monolithic ebuilds for KDE 4.0.
70 </p>
71 @@ -62,8 +63,9 @@
72 <body>
73
74 <p>
75 -The latest KDE release, as of this writing, is 3.4.1, recently marked stable.
76 -Both split and monolithic ebuilds for it are present in Portage.
77 +The latest stable KDE release, as of this writing, is 3.4.3. The latest
78 +unstable (package.masked) is 3.5.0_beta2. Split and monolithic ebuilds for both
79 +releases are present in Portage.
80 </p>
81
82 <ul>
83 @@ -92,6 +94,7 @@
84 <p>
85 If you have KDE 3.3.x installed, you can simply <c>emerge kde-meta</c> to
86 install the 3.4.x split ebuilds without disturbing your existing installation.
87 +The same applies to 3.5.x.
88 </p>
89
90 <p>
91 @@ -162,7 +165,7 @@
92 </ul>
93 </li>
94 <li>
95 - Finally, the split ebuilds also allow more compile-time flexibility with
96 + Finally, the split ebuilds also allow more compile-time flexibility with
97 USE flags.
98 </li>
99 </ul>
100 @@ -208,8 +211,8 @@
101 It's been <uri link="http://bugs.gentoo.org/show_bug.cgi?id=11123">said</uri>
102 before that split ebuilds would take much more time to emerge than the
103 monolithic ones, due to the overhead of unpacking and running configure for
104 -every package. A complete <c>emerge kde-meta</c> could take 20-30% longer than a
105 -classic <c>emerge kde</c>, unacceptable in an already long compile.
106 +every package. A complete <c>emerge kde-meta</c> could take 20-30% longer
107 +than a classic <c>emerge kde</c>, unacceptable in an already long compile.
108 </p>
109
110 <p>
111 @@ -220,22 +223,23 @@
112 </p>
113
114 <p>
115 -On the face of it, this analysis looks bleak. However, several factors which
116 -offset this slowdown will be detailed in the next sections.
117 +Finally, a split ebuild needs to extract specific files out of a large tarball.
118 +This is slower than extracting a dedicated, small tarball. However, creating
119 +such small tarballs for the autotools-based build system of KDE 3.x is
120 +difficult.
121 </p>
122
123 <p>
124 It is worth reiterating here that with the split ebuilds a KDE upgrade's
125 -compilation time can be cut by half - and in some cases by a factor of ten or
126 -more - by only upgrading the packages that actually changed. The benefit from a
127 -single such update often overshadows the overhead incurred during the original
128 -installation.
129 +compilation time can be greatly reduced by only upgrading the packages that
130 +actually changed. The benefit from a single such update often overshadows the
131 +overhead incurred during the original installation.
132 </p>
133
134 <p>
135 Finally, installing all of KDE makes sense if you want to explore the available
136 -packages or are setting up a multi-user environment; however, most people
137 -use only some of the 300+ KDE apps available. Anyone who really cares about
138 +packages or are setting up a multi-user environment; however, most people use
139 +only some of the 300+ KDE apps available. Anyone who really cares about
140 compilation time, such as owners of older boxen, can gain more time by
141 selectively installing packages than they might lose by the overhead incurred.
142 </p>
143 @@ -247,62 +251,54 @@
144 <body>
145
146 <p>
147 -The most obvious improvement would be to distribute separate tarballs for the
148 -split ebuilds, instead of unpacking pieces of the monolithic tarballs (kdebase
149 -etc.) distributed by upstream. This would eliminate two of the three
150 -overhead factors slowing down the split ebuilds: repeated extraction of the
151 -large tarballs and makefile regeneration (the <c>make -f
152 -admin/Makefile.cvs</c> phase mentioned above).
153 +Most or even all of the split ebuilds' performance issues are tied to autotools
154 +- autoconf, automake and other tools which manage the <c>./configure;make;make
155 +install</c> build system used in KDE 3.x.
156 </p>
157
158 <p>
159 -This leaves us with the issue of repeatedly running configure. The proper
160 -solution to this is confcache: a configure cache shared between emerge runs. An
161 -implementation already exists in the development branch of portage (the tool,
162 -not the package tree); a stable release with confcache is expected in half a
163 -year or so.
164 +KDE 4 will (as far as we can tell now) adopt a completely new build system,
165 +which among other things will greatly reduce the time its equivalent of a
166 +<c>make -f admin/Makefile.common; ./configure</c> will take. Hopefully, it will
167 +also make it much easier to create a small tarball for each split ebuild by
168 +lowering the cost of generating its equivalent of configure scripts (if any).
169 +</p>
170 +
171 +<p>
172 +Previously, confcache had been considered as a way to lower the cost of
173 +repeatedly running autoconf-generated configure scripts. Confcache is a
174 +method of caching the results of configure tests. However, there is still no
175 +confcache implementation in the stable (2.0) portage tree. Even if one is added
176 +in the future, it may not come soon enough for us to work on using it in the
177 +KDE ebuilds; we may elect to wait for KDE 4.
178 </p>
179
180 </body>
181 </section>
182 +</chapter>
183 +
184 +<chapter>
185 +<title>Split ebuilds FAQ</title>
186 <section>
187 -<title>Other factors offsetting split ebuilds slowdown</title>
188 +<title>Why are some split packages missing the newest ebuild versions?</title>
189 <body>
190
191 <p>
192 -The previous section listed methods of improving the performance of the
193 -split ebuilds specifically. Next, we will briefly mention some future speedups
194 -which are equally applicable to the monolithic ebuilds. Such speedups help
195 -make the split ebuilds 'fast enough', apart from comparisons with less
196 -featureful solutions such as the monolithic ebuilds.
197 +As explained above, not all applications are really updated between minor KDE
198 +releases, and so not all applications receive new ebuild versions. For
199 +instance, libkdenetwork wasn't updated in 3.5.0_beta2, so the latest ebuild
200 +available with that release was 3.5_beta1.
201 </p>
202
203 -<ul>
204 - <li>
205 - KDE 4.0 should be able to use <uri
206 - link="http://www.kde.me.uk/index.php?page=unsermake">unsermake</uri>
207 - instead of automake, which speeds up compilation in some scenarios; our KDE
208 - 3.4 ebuilds may eventually use unsermake as well.
209 - </li>
210 - <li>
211 - The split ebuilds support the kdexdeltas USE flag, which allows downloading
212 - binary diffs between release tarballs to save on bandwidth usage.
213
214
215
216 --
217 gentoo-doc-cvs@g.o mailing list