From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7272 invoked from network); 25 Jul 2004 21:39:54 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 25 Jul 2004 21:39:54 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1Boqin-0005h7-AN for arch-gentoo-dev@lists.gentoo.org; Sun, 25 Jul 2004 21:39:53 +0000 Received: (qmail 3943 invoked by uid 89); 25 Jul 2004 21:39:52 +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 11745 invoked from network); 25 Jul 2004 21:39:52 +0000 Message-ID: <00b901c4728f$eae19a80$0500a8c0@EPOX2> From: "Gavin" To: References: <0FD0031C-DD92-11D8-B5A6-000D93283962@gentoo.org> <4102CC74.1020709@gentoo.org> <7760.205.241.48.33.1090715661.squirrel@spidermail.richmond.edu> <1090785447.7929.3.camel@localhost> <41044B4B.70103@gentoo.org> Date: Sun, 25 Jul 2004 14:38:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Subject: Re: [gentoo-dev] Re: New drivers category in portage (Was [gentoo-dev] macos mess) X-Archives-Salt: 523895ec-6d44-4fc0-94a7-fefc066506a9 X-Archives-Hash: 9e235333214ce739300b3a08864ef3af > linux, etc.) and I second spyderous' suggestion of drivers-${TYPE}. I'm currently using RSYNC_EXCLUDEFROM in /etc/make.conf with a = hand-edited list of patterns describing files that are irrelevant to my = platform/config/needs/etc., to almost cut in half the number of files = sync'd by 'emerge sync'. If we're adding another dimension of things that are irrelevant to my = platform, is there a better way of avoiding the wasted bandwidth = incurred by emerge sync'ing without resorting to a manually maintained = list referenced by RSYNC_EXCLUDEFROM? If every ebuild had "type/kind/purpose/etc." classifications, then I = could define combinations of classifications with different update = (emerge sync) priorities/frequencies, vastly reducing both bandwidth = consumption and my time required to maintain this bandwidth reduction = system for emerge sync's. Obviously, such a system needs "smarts" to = know what which ebuilds must be fetched, regardless of classification = priorities (e.g. depends on which packages are already emerged and their = current/new dependencies). BTW, I joined this list recently, and I haven't been tracking portage = development, so I probably=20 missed something relevant. If the ideas above are old hat, just press = 'delete' .. Cheers, Gavin -- gentoo-dev@gentoo.org mailing list