nightmorph 06/09/28 11:40:41 Modified: kde-split-ebuilds.xml Log: Updated kde split ebuilds guide, kickstarted (see, a k-pun) by deathwing00. see bug 149149
Revision Changes Path 1.11 xml/htdocs/doc/en/kde-split-ebuilds.xml file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/kde-split-ebuilds.xml?rev=1.11&view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/kde-split-ebuilds.xml?rev=1.11&content-type=text/plain diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/kde-split-ebuilds.xml?r1=1.10&r2=1.11 Index: kde-split-ebuilds.xml =================================================================== RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/en/kde-split-ebuilds.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- kde-split-ebuilds.xml 2 Jan 2006 10:05:11 -0000 1.10 +++ kde-split-ebuilds.xml 28 Sep 2006 11:40:41 -0000 1.11 @@ -1,6 +1,6 @@ <?xml version='1.0' encoding='UTF-8'?> -<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/kde-split-ebuilds.xml,v 1.10 2006/01/02 10:05:11 neysx Exp $ --> +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/kde-split-ebuilds.xml,v 1.11 2006/09/28 11:40:41 nightmorph Exp $ --> <!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> @@ -25,8 +25,8 @@ <!-- See http://creativecommons.org/licenses/by-sa/2.5 --> <license/> -<version>1.7</version> -<date>2005-11-30</date> +<version>1.8</version> +<date>2006-09-28</date> <chapter> <title>The Split KDE Ebuilds</title> @@ -36,27 +36,27 @@ <p> Until January 2005, the only KDE ebuilds in Portage were 'monolithic' ones. -That is to say, there were only 15 ebuilds (kdebase, kdenetwork, ...), and -each one installed many applications that did not, in fact, depend on one -another. This was clearly a suboptimal situation, and not very Gentoo-ish, +That is to say, there were only 15 ebuilds (<c>kdebase</c>, <c>kdenetwork</c>, +...), and each one installed many applications that did not, in fact, depend on +one another. This was clearly a suboptimal situation, and not very Gentoo-ish, but it was tolerated for a long time. </p> <p> -The new 'split' ebuilds (for konqueror, kmail, ...) rectified the situation by -providing separate ebuilds for all the separate KDE applications. This gave us -a grand total of about 330 new ebuilds in the kde-base category. +The new 'split' ebuilds (for <c>konqueror</c>, <c>kmail</c>, ...) rectified the +situation by providing separate ebuilds for all the separate KDE applications. +This gave us a grand total of about 330 new ebuilds in the kde-base category. </p> <p> -We still provide monolithic ebuilds for KDE 3.4 and 3.5 and they are cleanly -interoperable with the split ones. However, the split ebuilds are the new -default, and there will be no monolithic ebuilds for KDE 4.0. +We still provide monolithic ebuilds for 3.5 and they are cleanly interoperable +with the split ones. However, the split ebuilds are the new default, and there +will be no monolithic ebuilds for KDE 4.0. </p> <p> Finally, it should be mentioned that there are split ebuilds for Koffice as -well. These provide kword, kugar etc. as separate packages. +well. These provide <c>kword</c>, <c>kugar</c>, etc. as separate packages. </p> </body> @@ -66,9 +66,9 @@ <body> <p> -The latest stable KDE release, as of this writing, is 3.4.3. The latest -unstable (package.masked) is 3.5.0_beta2. Split and monolithic ebuilds for both -releases are present in Portage. +The latest stable KDE release, as of this writing, is 3.5.2. The latest +unstable (~arch) is 3.5.4. Split and monolithic ebuilds for both releases are +present in Portage. </p> <ul> @@ -83,8 +83,8 @@ <li> Finally, for the exact equivalent of one of the monolithic packages - for instance, to get all the applications included in <c>kdebase</c> using - split ebuilds - you can <c>emerge kdebase-meta</c> (or kdepim-meta, etc.) - To get absolutely all KDE split ebuilds, <c>emerge kde-meta</c>. + split ebuilds - you can <c>emerge kdebase-meta</c> (or <c>kdepim-meta</c>, + etc.) To get absolutely all KDE split ebuilds, <c>emerge kde-meta</c>. </li> </ul> @@ -96,20 +96,21 @@ <p> If you have KDE 3.3.x installed, you can simply <c>emerge kde-meta</c> to -install the 3.4.x split ebuilds without disturbing your existing installation. -The same applies to 3.5.x. +install the 3.5.x split ebuilds without disturbing your existing installation. </p> <p> -If you have the KDE 3.4.x monolithic ebuilds installed, you must unmerge them -before emerging the split ebuilds. However, this process can be done for each -monolithic ebuild in turn; you don't have to unmerge all of KDE at once. +If you have the KDE 3.4.x or 3.5.x monolithic ebuilds installed, you must +unmerge them before emerging the split ebuilds. However, this process can be +done for each monolithic ebuild in turn; you don't have to unmerge all of KDE +at once. </p> <p> -If you're in doubt, remember there are blocking deps in place between each -monolithic ebuild and the split ebuilds derived from it. Portage won't allow an -illegal state to be created, so any emerge or unmerge it allows is OK. +If you're in doubt, remember there are blocking dependencies in place between +each monolithic ebuild and the split ebuilds derived from it. Portage won't +allow an illegal state to be created, so any emerge or unmerge it allows is +OK. </p> </body> @@ -138,7 +139,8 @@ </li> <li> Users of other desktops and leaner WMs can emerge a few KDE apps they like - without the (quite big) overhead of the rest of, say, kdebase or kdepim. + without the (quite big) overhead of the rest of, say, <c>kdebase</c> or + <c>kdepim</c>. </li> <li> Users can fine-tune the packages they have installed. Reasons you might @@ -146,9 +148,10 @@ <ul> <li> - You care about compilation time. <c>emerge kdebase kdepim kdenetwork</c> - takes far too long when what you really need is konqueror, kmail - and kopete. Besides, CPU time is money... somewhere. + You care about compilation time. <c>emerge kdebase kdepim + kdenetwork</c> takes far too long when what you really need is + <c>konqueror</c>, <c>kmail</c> and <c>kopete</c>. Besides, CPU time is + money... somewhere. </li> <li> You care about disk usage. Every unused package is that many megabytes @@ -182,8 +185,8 @@ <p> Split and monolithic ebuilds can be mixed freely. The only restriction is that a monolithic ebuild can't be installed at the same time as a split ebuild -deriving from it. There are blocking deps in the ebuilds that enforce this, so -you can do anything emerge allows you to do. +deriving from it. There are blocking dependencies in the ebuilds that enforce +this, so you can do anything emerge allows you to do. </p> <p> @@ -195,9 +198,9 @@ <p> The split ebuilds are also the default ebuilds. This means that when some other ebuild depends on a KDE application, it will want to install a split ebuild. -However, the matching monolithic ebuild will also satisfy that dep, so you can -emerge the monolithic ebuild manually and then emerge the ebuild that depended -on it. +However, the matching monolithic ebuild will also satisfy that dependency, so +you can emerge the monolithic ebuild manually and then emerge the ebuild that +depended on it. </p> </body> @@ -268,12 +271,12 @@ </p> <p> -Previously, confcache had been considered as a way to lower the cost of -repeatedly running autoconf-generated configure scripts. Confcache is a +Previously, <c>confcache</c> had been considered as a way to lower the cost of +repeatedly running autoconf-generated configure scripts. <c>Confcache</c> is a method of caching the results of configure tests. However, there is still no -confcache implementation in the stable (2.0) portage tree. Even if one is added -in the future, it may not come soon enough for us to work on using it in the -KDE ebuilds; we may elect to wait for KDE 4. +<c>confcache</c> implementation in the stable (2.1) Portage tree. Even if one +is added in the future, it may not come soon enough for us to work on using it +in the KDE ebuilds; we may elect to wait for KDE 4. </p> </body> @@ -311,7 +314,7 @@ allows selectively disabling subdirectories from compilation. Some people used to use it to compile subsets of the monolithic KDE ebuilds. For instance, running <c>DO_NOT_COMPILE=konqueror emerge kdebase</c> would install a kdebase -without the konqueror application. +without the <c>konqueror</c> application. </p> <p> @@ -327,7 +330,7 @@ <ul> <li> - It completely breaks portage's dependency tracking. Portage does not know + It completely breaks Portage's dependency tracking. Portage does not know about DO_NOT_COMPILE, and thinks the entire monolithic package has been installed and can satisfy other packages' deps. This can cause other packages not to emerge or not to run. @@ -346,7 +349,7 @@ sufficient knowledge on the user's part. The only thing you can do with it is disable a few applications from compiling. It is practically impossible to use it to install only a few selected applications from modules like - kdebase or kdepim. + <c>kdebase</c> or <c>kdepim</c>. </li> <li> If I installed kmail yesterday and want to add korn today, using @@ -377,7 +380,7 @@ For completeness' sake, I should mention that maintainers from other archs have in fact complained about the increased workload of testing and keywording so many separate ebuilds. We're working to resolve this and it's a major reason -why monolithic ebuilds are in fact still available for KDE 3.4. +why monolithic ebuilds are in fact still available for KDE 3.5. </p> </body> @@ -430,7 +433,7 @@ <p> The objective here is to list all split kde ebuilds derived from, say, the -kdebase monolithic ebuild. Once again, the proper implementation (such as <uri +<c>kdebase</c> monolithic ebuild. Once again, the proper implementation (such as <uri link="/proj/en/glep/glep-0021.html">GLEP 21</uri>) would make this trivial. Today, however, you must become involved in the KDE eclasses' implementation details to some degree. So, if you use any of these approaches in a script -- [email protected] mailing list
