The Split KDE Ebuilds

From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1EWHsx-0004E9-1v for garchives@archives.gentoo.org; Sun, 30 Oct 2005 18:26:27 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id j9UIQKIF031032; Sun, 30 Oct 2005 18:26:20 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id j9UIQJ48027058 for ; Sun, 30 Oct 2005 18:26:19 GMT Message-Id: <200510301826.j9UIQJ48027058@robin.gentoo.org> Received: from lark.gentoo.osuosl.org ([140.211.166.177] helo=lark.gentoo.org) by smtp.gentoo.org with smtp (Exim 4.43) id 1EWHso-0006tD-M4 for gentoo-doc-cvs@lists.gentoo.org; Sun, 30 Oct 2005 18:26:18 +0000 Received: by lark.gentoo.org (sSMTP sendmail emulation); Sun, 30 Oct 2005 18:26:17 +0000 From: "Stefano Rossi" Date: Sun, 30 Oct 2005 18:26:17 +0000 To: gentoo-doc-cvs@lists.gentoo.org Subject: [gentoo-doc-cvs] cvs commit: kde-split-ebuilds.xml Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-doc-cvs@gentoo.org Reply-to: docs-team@lists.gentoo.org X-Archives-Salt: d711527a-f012-4b64-b41d-b1b9278a210d X-Archives-Hash: 2b7cb15dd62e95bca8d8fa905dc58484 so 05/10/30 18:26:17 Modified: xml/htdocs/doc/en kde-split-ebuilds.xml Log: #110460 updated KDE split ebuilds Revision Changes Path 1.8 +61 -65 xml/htdocs/doc/en/kde-split-ebuilds.xml 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 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 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 Index: kde-split-ebuilds.xml =================================================================== RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/en/kde-split-ebuilds.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- kde-split-ebuilds.xml 9 Sep 2005 07:26:39 -0000 1.7 +++ kde-split-ebuilds.xml 30 Oct 2005 18:26:17 -0000 1.8 @@ -1,6 +1,6 @@ - + @@ -22,8 +22,8 @@ -1.5 -2005-07-02 +1.6 +2005-10-30 The Split KDE Ebuilds @@ -32,20 +32,21 @@

-Until January 2005, the only KDE ebuilds in Portage were 'monolithic' ones. That -is to say, there were only 15 ebuilds, 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. +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, +but it was tolerated for a long time.

-The new 'split' ebuilds 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 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.

-We still provide monolithic ebuilds for KDE 3.4 and they are cleanly +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.

@@ -62,8 +63,9 @@

-The latest KDE release, as of this writing, is 3.4.1, recently marked stable. -Both split and monolithic ebuilds for it are present in Portage. +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.

If you have KDE 3.3.x installed, you can simply emerge kde-meta to install the 3.4.x split ebuilds without disturbing your existing installation. +The same applies to 3.5.x.

@@ -162,7 +165,7 @@

- Finally, the split ebuilds also allow more compile-time flexibility with + Finally, the split ebuilds also allow more compile-time flexibility with USE flags.

@@ -208,8 +211,8 @@ It's been said before that split ebuilds would take much more time to emerge than the monolithic ones, due to the overhead of unpacking and running configure for -every package. A complete emerge kde-meta could take 20-30% longer than a -classic emerge kde, unacceptable in an already long compile. +every package. A complete emerge kde-meta could take 20-30% longer +than a classic emerge kde, unacceptable in an already long compile.

@@ -220,22 +223,23 @@

-On the face of it, this analysis looks bleak. However, several factors which -offset this slowdown will be detailed in the next sections. +Finally, a split ebuild needs to extract specific files out of a large tarball. +This is slower than extracting a dedicated, small tarball. However, creating +such small tarballs for the autotools-based build system of KDE 3.x is +difficult.

It is worth reiterating here that with the split ebuilds a KDE upgrade's -compilation time can be cut by half - and in some cases by a factor of ten or -more - by only upgrading the packages that actually changed. The benefit from a -single such update often overshadows the overhead incurred during the original -installation. +compilation time can be greatly reduced by only upgrading the packages that +actually changed. The benefit from a single such update often overshadows the +overhead incurred during the original installation.

Finally, installing all of KDE makes sense if you want to explore the available -packages or are setting up a multi-user environment; however, most people -use only some of the 300+ KDE apps available. Anyone who really cares about +packages or are setting up a multi-user environment; however, most people use +only some of the 300+ KDE apps available. Anyone who really cares about compilation time, such as owners of older boxen, can gain more time by selectively installing packages than they might lose by the overhead incurred.

@@ -247,62 +251,54 @@

-The most obvious improvement would be to distribute separate tarballs for the -split ebuilds, instead of unpacking pieces of the monolithic tarballs (kdebase -etc.) distributed by upstream. This would eliminate two of the three -overhead factors slowing down the split ebuilds: repeated extraction of the -large tarballs and makefile regeneration (the make -f -admin/Makefile.cvs phase mentioned above). +Most or even all of the split ebuilds' performance issues are tied to autotools +- autoconf, automake and other tools which manage the ./configure;make;make +install build system used in KDE 3.x.

-This leaves us with the issue of repeatedly running configure. The proper -solution to this is confcache: a configure cache shared between emerge runs. An -implementation already exists in the development branch of portage (the tool, -not the package tree); a stable release with confcache is expected in half a -year or so. +KDE 4 will (as far as we can tell now) adopt a completely new build system, +which among other things will greatly reduce the time its equivalent of a +make -f admin/Makefile.common; ./configure will take. Hopefully, it will +also make it much easier to create a small tarball for each split ebuild by +lowering the cost of generating its equivalent of configure scripts (if any). +

+ +

+Previously, confcache had been considered as a way to lower the cost of +repeatedly running autoconf-generated configure scripts. Confcache 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.

+ + + +Split ebuilds FAQ

-Other factors offsetting split ebuilds slowdown +Why are some split packages missing the newest ebuild versions?

-The previous section listed methods of improving the performance of the -split ebuilds specifically. Next, we will briefly mention some future speedups -which are equally applicable to the monolithic ebuilds. Such speedups help -make the split ebuilds 'fast enough', apart from comparisons with less -featureful solutions such as the monolithic ebuilds. +As explained above, not all applications are really updated between minor KDE +releases, and so not all applications receive new ebuild versions. For +instance, libkdenetwork wasn't updated in 3.5.0_beta2, so the latest ebuild +available with that release was 3.5_beta1.

-

- KDE 4.0 should be able to use unsermake - instead of automake, which speeds up compilation in some scenarios; our KDE - 3.4 ebuilds may eventually use unsermake as well. -
- The split ebuilds support the kdexdeltas USE flag, which allows downloading - binary diffs between release tarballs to save on bandwidth usage. -- gentoo-doc-cvs@gentoo.org mailing list