| 1 |
nightmorph 06/09/28 11:40:41 |
| 2 |
|
| 3 |
Modified: kde-split-ebuilds.xml |
| 4 |
Log: |
| 5 |
Updated kde split ebuilds guide, kickstarted (see, a k-pun) by deathwing00. see bug 149149 |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.11 xml/htdocs/doc/en/kde-split-ebuilds.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/kde-split-ebuilds.xml?rev=1.11&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/kde-split-ebuilds.xml?rev=1.11&content-type=text/plain |
| 12 |
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/kde-split-ebuilds.xml?r1=1.10&r2=1.11 |
| 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.10 |
| 18 |
retrieving revision 1.11 |
| 19 |
diff -u -r1.10 -r1.11 |
| 20 |
--- kde-split-ebuilds.xml 2 Jan 2006 10:05:11 -0000 1.10 |
| 21 |
+++ kde-split-ebuilds.xml 28 Sep 2006 11:40:41 -0000 1.11 |
| 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.10 2006/01/02 10:05:11 neysx Exp $ --> |
| 26 |
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/kde-split-ebuilds.xml,v 1.11 2006/09/28 11:40:41 nightmorph Exp $ --> |
| 27 |
|
| 28 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 29 |
|
| 30 |
@@ -25,8 +25,8 @@ |
| 31 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> |
| 32 |
<license/> |
| 33 |
|
| 34 |
-<version>1.7</version> |
| 35 |
-<date>2005-11-30</date> |
| 36 |
+<version>1.8</version> |
| 37 |
+<date>2006-09-28</date> |
| 38 |
|
| 39 |
<chapter> |
| 40 |
<title>The Split KDE Ebuilds</title> |
| 41 |
@@ -36,27 +36,27 @@ |
| 42 |
|
| 43 |
<p> |
| 44 |
Until January 2005, the only KDE ebuilds in Portage were 'monolithic' ones. |
| 45 |
-That is to say, there were only 15 ebuilds (kdebase, kdenetwork, ...), and |
| 46 |
-each one installed many applications that did not, in fact, depend on one |
| 47 |
-another. This was clearly a suboptimal situation, and not very Gentoo-ish, |
| 48 |
+That is to say, there were only 15 ebuilds (<c>kdebase</c>, <c>kdenetwork</c>, |
| 49 |
+...), and each one installed many applications that did not, in fact, depend on |
| 50 |
+one another. This was clearly a suboptimal situation, and not very Gentoo-ish, |
| 51 |
but it was tolerated for a long time. |
| 52 |
</p> |
| 53 |
|
| 54 |
<p> |
| 55 |
-The new 'split' ebuilds (for konqueror, kmail, ...) rectified the situation by |
| 56 |
-providing separate ebuilds for all the separate KDE applications. This gave us |
| 57 |
-a grand total of about 330 new ebuilds in the kde-base category. |
| 58 |
+The new 'split' ebuilds (for <c>konqueror</c>, <c>kmail</c>, ...) rectified the |
| 59 |
+situation by providing separate ebuilds for all the separate KDE applications. |
| 60 |
+This gave us a grand total of about 330 new ebuilds in the kde-base category. |
| 61 |
</p> |
| 62 |
|
| 63 |
<p> |
| 64 |
-We still provide monolithic ebuilds for KDE 3.4 and 3.5 and they are cleanly |
| 65 |
-interoperable with the split ones. However, the split ebuilds are the new |
| 66 |
-default, and there will be no monolithic ebuilds for KDE 4.0. |
| 67 |
+We still provide monolithic ebuilds for 3.5 and they are cleanly interoperable |
| 68 |
+with the split ones. However, the split ebuilds are the new default, and there |
| 69 |
+will be no monolithic ebuilds for KDE 4.0. |
| 70 |
</p> |
| 71 |
|
| 72 |
<p> |
| 73 |
Finally, it should be mentioned that there are split ebuilds for Koffice as |
| 74 |
-well. These provide kword, kugar etc. as separate packages. |
| 75 |
+well. These provide <c>kword</c>, <c>kugar</c>, etc. as separate packages. |
| 76 |
</p> |
| 77 |
|
| 78 |
</body> |
| 79 |
@@ -66,9 +66,9 @@ |
| 80 |
<body> |
| 81 |
|
| 82 |
<p> |
| 83 |
-The latest stable KDE release, as of this writing, is 3.4.3. The latest |
| 84 |
-unstable (package.masked) is 3.5.0_beta2. Split and monolithic ebuilds for both |
| 85 |
-releases are present in Portage. |
| 86 |
+The latest stable KDE release, as of this writing, is 3.5.2. The latest |
| 87 |
+unstable (~arch) is 3.5.4. Split and monolithic ebuilds for both releases are |
| 88 |
+present in Portage. |
| 89 |
</p> |
| 90 |
|
| 91 |
<ul> |
| 92 |
@@ -83,8 +83,8 @@ |
| 93 |
<li> |
| 94 |
Finally, for the exact equivalent of one of the monolithic packages - for |
| 95 |
instance, to get all the applications included in <c>kdebase</c> using |
| 96 |
- split ebuilds - you can <c>emerge kdebase-meta</c> (or kdepim-meta, etc.) |
| 97 |
- To get absolutely all KDE split ebuilds, <c>emerge kde-meta</c>. |
| 98 |
+ split ebuilds - you can <c>emerge kdebase-meta</c> (or <c>kdepim-meta</c>, |
| 99 |
+ etc.) To get absolutely all KDE split ebuilds, <c>emerge kde-meta</c>. |
| 100 |
</li> |
| 101 |
</ul> |
| 102 |
|
| 103 |
@@ -96,20 +96,21 @@ |
| 104 |
|
| 105 |
<p> |
| 106 |
If you have KDE 3.3.x installed, you can simply <c>emerge kde-meta</c> to |
| 107 |
-install the 3.4.x split ebuilds without disturbing your existing installation. |
| 108 |
-The same applies to 3.5.x. |
| 109 |
+install the 3.5.x split ebuilds without disturbing your existing installation. |
| 110 |
</p> |
| 111 |
|
| 112 |
<p> |
| 113 |
-If you have the KDE 3.4.x monolithic ebuilds installed, you must unmerge them |
| 114 |
-before emerging the split ebuilds. However, this process can be done for each |
| 115 |
-monolithic ebuild in turn; you don't have to unmerge all of KDE at once. |
| 116 |
+If you have the KDE 3.4.x or 3.5.x monolithic ebuilds installed, you must |
| 117 |
+unmerge them before emerging the split ebuilds. However, this process can be |
| 118 |
+done for each monolithic ebuild in turn; you don't have to unmerge all of KDE |
| 119 |
+at once. |
| 120 |
</p> |
| 121 |
|
| 122 |
<p> |
| 123 |
-If you're in doubt, remember there are blocking deps in place between each |
| 124 |
-monolithic ebuild and the split ebuilds derived from it. Portage won't allow an |
| 125 |
-illegal state to be created, so any emerge or unmerge it allows is OK. |
| 126 |
+If you're in doubt, remember there are blocking dependencies in place between |
| 127 |
+each monolithic ebuild and the split ebuilds derived from it. Portage won't |
| 128 |
+allow an illegal state to be created, so any emerge or unmerge it allows is |
| 129 |
+OK. |
| 130 |
</p> |
| 131 |
|
| 132 |
</body> |
| 133 |
@@ -138,7 +139,8 @@ |
| 134 |
</li> |
| 135 |
<li> |
| 136 |
Users of other desktops and leaner WMs can emerge a few KDE apps they like |
| 137 |
- without the (quite big) overhead of the rest of, say, kdebase or kdepim. |
| 138 |
+ without the (quite big) overhead of the rest of, say, <c>kdebase</c> or |
| 139 |
+ <c>kdepim</c>. |
| 140 |
</li> |
| 141 |
<li> |
| 142 |
Users can fine-tune the packages they have installed. Reasons you might |
| 143 |
@@ -146,9 +148,10 @@ |
| 144 |
|
| 145 |
<ul> |
| 146 |
<li> |
| 147 |
- You care about compilation time. <c>emerge kdebase kdepim kdenetwork</c> |
| 148 |
- takes far too long when what you really need is konqueror, kmail |
| 149 |
- and kopete. Besides, CPU time is money... somewhere. |
| 150 |
+ You care about compilation time. <c>emerge kdebase kdepim |
| 151 |
+ kdenetwork</c> takes far too long when what you really need is |
| 152 |
+ <c>konqueror</c>, <c>kmail</c> and <c>kopete</c>. Besides, CPU time is |
| 153 |
+ money... somewhere. |
| 154 |
</li> |
| 155 |
<li> |
| 156 |
You care about disk usage. Every unused package is that many megabytes |
| 157 |
@@ -182,8 +185,8 @@ |
| 158 |
<p> |
| 159 |
Split and monolithic ebuilds can be mixed freely. The only restriction is that |
| 160 |
a monolithic ebuild can't be installed at the same time as a split ebuild |
| 161 |
-deriving from it. There are blocking deps in the ebuilds that enforce this, so |
| 162 |
-you can do anything emerge allows you to do. |
| 163 |
+deriving from it. There are blocking dependencies in the ebuilds that enforce |
| 164 |
+this, so you can do anything emerge allows you to do. |
| 165 |
</p> |
| 166 |
|
| 167 |
<p> |
| 168 |
@@ -195,9 +198,9 @@ |
| 169 |
<p> |
| 170 |
The split ebuilds are also the default ebuilds. This means that when some other |
| 171 |
ebuild depends on a KDE application, it will want to install a split ebuild. |
| 172 |
-However, the matching monolithic ebuild will also satisfy that dep, so you can |
| 173 |
-emerge the monolithic ebuild manually and then emerge the ebuild that depended |
| 174 |
-on it. |
| 175 |
+However, the matching monolithic ebuild will also satisfy that dependency, so |
| 176 |
+you can emerge the monolithic ebuild manually and then emerge the ebuild that |
| 177 |
+depended on it. |
| 178 |
</p> |
| 179 |
|
| 180 |
</body> |
| 181 |
@@ -268,12 +271,12 @@ |
| 182 |
</p> |
| 183 |
|
| 184 |
<p> |
| 185 |
-Previously, confcache had been considered as a way to lower the cost of |
| 186 |
-repeatedly running autoconf-generated configure scripts. Confcache is a |
| 187 |
+Previously, <c>confcache</c> had been considered as a way to lower the cost of |
| 188 |
+repeatedly running autoconf-generated configure scripts. <c>Confcache</c> is a |
| 189 |
method of caching the results of configure tests. However, there is still no |
| 190 |
-confcache implementation in the stable (2.0) portage tree. Even if one is added |
| 191 |
-in the future, it may not come soon enough for us to work on using it in the |
| 192 |
-KDE ebuilds; we may elect to wait for KDE 4. |
| 193 |
+<c>confcache</c> implementation in the stable (2.1) Portage tree. Even if one |
| 194 |
+is added in the future, it may not come soon enough for us to work on using it |
| 195 |
+in the KDE ebuilds; we may elect to wait for KDE 4. |
| 196 |
</p> |
| 197 |
|
| 198 |
</body> |
| 199 |
@@ -311,7 +314,7 @@ |
| 200 |
allows selectively disabling subdirectories from compilation. Some people used |
| 201 |
to use it to compile subsets of the monolithic KDE ebuilds. For instance, |
| 202 |
running <c>DO_NOT_COMPILE=konqueror emerge kdebase</c> would install a kdebase |
| 203 |
-without the konqueror application. |
| 204 |
+without the <c>konqueror</c> application. |
| 205 |
</p> |
| 206 |
|
| 207 |
<p> |
| 208 |
@@ -327,7 +330,7 @@ |
| 209 |
|
| 210 |
<ul> |
| 211 |
<li> |
| 212 |
- It completely breaks portage's dependency tracking. Portage does not know |
| 213 |
+ It completely breaks Portage's dependency tracking. Portage does not know |
| 214 |
about DO_NOT_COMPILE, and thinks the entire monolithic package has been |
| 215 |
installed and can satisfy other packages' deps. This can cause other |
| 216 |
packages not to emerge or not to run. |
| 217 |
@@ -346,7 +349,7 @@ |
| 218 |
sufficient knowledge on the user's part. The only thing you can do with it |
| 219 |
is disable a few applications from compiling. It is practically impossible |
| 220 |
to use it to install only a few selected applications from modules like |
| 221 |
- kdebase or kdepim. |
| 222 |
+ <c>kdebase</c> or <c>kdepim</c>. |
| 223 |
</li> |
| 224 |
<li> |
| 225 |
If I installed kmail yesterday and want to add korn today, using |
| 226 |
@@ -377,7 +380,7 @@ |
| 227 |
For completeness' sake, I should mention that maintainers from other archs |
| 228 |
have in fact complained about the increased workload of testing and keywording |
| 229 |
so many separate ebuilds. We're working to resolve this and it's a major reason |
| 230 |
-why monolithic ebuilds are in fact still available for KDE 3.4. |
| 231 |
+why monolithic ebuilds are in fact still available for KDE 3.5. |
| 232 |
</p> |
| 233 |
|
| 234 |
</body> |
| 235 |
@@ -430,7 +433,7 @@ |
| 236 |
|
| 237 |
<p> |
| 238 |
The objective here is to list all split kde ebuilds derived from, say, the |
| 239 |
-kdebase monolithic ebuild. Once again, the proper implementation (such as <uri |
| 240 |
+<c>kdebase</c> monolithic ebuild. Once again, the proper implementation (such as <uri |
| 241 |
link="/proj/en/glep/glep-0021.html">GLEP 21</uri>) would make this trivial. |
| 242 |
Today, however, you must become involved in the KDE eclasses' implementation |
| 243 |
details to some degree. So, if you use any of these approaches in a script |
| 244 |
|
| 245 |
|
| 246 |
|
| 247 |
-- |
| 248 |
gentoo-doc-cvs@g.o mailing list |
Archives