From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30439 invoked from network); 19 Oct 2004 19:34:38 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 19 Oct 2004 19:34:38 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CJzkW-0003gJ-5P for arch-gentoo-dev@lists.gentoo.org; Tue, 19 Oct 2004 19:34:24 +0000 Received: (qmail 15645 invoked by uid 89); 19 Oct 2004 19:33:48 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 19152 invoked from network); 19 Oct 2004 19:33:48 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Date: Tue, 19 Oct 2004 12:33:14 -0700 Organization: Sometimes Message-ID: References: <200410191926.13381.danarmak@gentoo.org> <921ad39e0410191122373d1d2f@mail.gmail.com> <921ad39e04101911233080f050@mail.gmail.com> <200410192040.54826.danarmak@gentoo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-66-58.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news Subject: [gentoo-dev] Re: ANN: broken-up kde ebuilds (aka 'emerge kmail') X-Archives-Salt: 65e93b99-e781-4ec0-9d36-973e78d0d070 X-Archives-Hash: aff9ae96f64ce263c0d52aef43a080f6 Dan Armak posted <200410192040.54826.danarmak@gentoo.org>, excerpted below, on Tue, 19 Oct 2004 20:40:54 +0200: > On Tuesday 19 October 2004 20:23, Roman Gaufman wrote: >> err, DO_NOT_COMPILE="kmail" in /etc/make.conf does just that, and >> supports every package or even service KDE has to offer. Feel free to >> not compile ksmserver or kinit as well -- this will break things, but >> the fact is, gentooists always had the possibility to do this! >> >> What exactly do you propose here? -- do you actually propose gentoo >> developers should split the metapackages into close to 100 ebuilds? -- > > I'm not proposing anything. I'm announcing the fact that I and another > Gentoo developer (motaboy) have actually split the monolithic ebuilds > into well over 300 new packages. Wow! >> what gain over DO_NOT_COMPILE does this give? > > It allows portage to manage interdependencies and, in fact, everything > else it manages. Heavy use of DO_NOT_COMPILE, such as emerging only > kmail + its deps from all of kdepim (of course each user has to figure > out for himself what those deps are, first), is more or less equivalent > to linux from scratch. It'd be manual building, except portage will > think it knows what is installed, and will be wrong. Interestingly, I just bit the bullet with 3.3.1 and configured all those DO_NOT_COMPILEs for myself. Some packages (kdebase, kdegames) I emerged intact, others (kdeadmin, kdepim) I killed more than half the package. kdepim was the worst to try to handle, as I had to backtrack on a couple items (libical and libkcal) and compile them anyway due to dependency issues. KMail and KNode were the main apps I wanted out of it, plus stuff like the kfile metadata helpers. kdeartwork I just killed the screensavers. A couple packages (kdeedu) I don't install at all anyway. I had originally tried to use KDE_REMOVE_DIR from the ebuilds, but found some stuff that didn't need actually compiled but DID need the dirs still there for headers, etc. (kpilot was one of these, altho it wasn't compiled anyway due to use flag.) I went back to DO_NOT_COMPILE. Good point re portage tracking. How do you manage the dependencies? Do you rebuild every time in-builddir, or do you look in the deployed system first and only build in-builddir if it isn't yet deployed? Is there a list of an optimal emerge order if the latter? I've been thinking about confcache. I haven't tried using it yet, but I'm certainly thinking about it. Does it just do the main stuff, or does it handle the entire configure step? From earlier, I remember you (?) saying what it DID cache, it invalidated entirely if there was just one change. I can see how this would be simpler to implement. However, if you are caching everything, I'd hope you are doing it in segments, so that for instance the normal C compile checks on endianness and bitlength and the like, the "main" checks, are not invalidated when something like qt changes. Perhaps section it into "main system qualities" like endianness and the like that aren't likely to change, "standard bintools" checks,"gcc", "kde/qt", "gtk/gnome", and "misc" (off the top of my head)? That would maintain a grouping, but wouldn't invalidate the entire confcache for one change to the kde dependencies with the 300 kde packages you mention. As I said, however, I haven't yet used it, just been turning the idea over in my head, so... -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin -- gentoo-dev@gentoo.org mailing list