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 |