From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 955001381F4 for ; Wed, 15 Aug 2012 18:23:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BEC4721C02A; Wed, 15 Aug 2012 18:22:56 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 10C6621C00B for ; Wed, 15 Aug 2012 18:21:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 752F51B402C for ; Wed, 15 Aug 2012 18:21:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5.5 tests=[AWL=-1.472, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQjkkHkFQu9T for ; Wed, 15 Aug 2012 18:21:35 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 757471B4022 for ; Wed, 15 Aug 2012 18:21:34 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T1iDg-0001ay-CE for gentoo-dev@gentoo.org; Wed, 15 Aug 2012 20:21:28 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Aug 2012 20:21:28 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Aug 2012 20:21:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Questions about SystemD and OpenRC Date: Wed, 15 Aug 2012 18:21:14 +0000 (UTC) Message-ID: References: <1344366029.24762.31.camel@TesterTop4> <502377E7.8010803@gentoo.org> <1344535966.2121.6.camel@TesterTop4> <20120809183130.GA6795@linux1> <20120809195727.5d04ccff@googlemail.com> <20120814032416.GA8489@kroah.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.139 (Sexual Chocolate; GIT 1f91845 /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: 4e1111de-f233-471f-b6ed-4cf06177b6a1 X-Archives-Hash: 884b7b2dc58482c07cfb15dfd8da0a26 Rich Freeman posted on Wed, 15 Aug 2012 06:27:41 -0400 as excerpted: > Right now having decent KDE and Gnome support with all the bells and > whistles[...] isn't that hard, [It] will likely get harder, which means > in practice what we'll probably have is a reasonable compromise which > will never be quite as polished in any one direction as it could be, > unless the end user does the polishing. Well stated. > RE you concerns about OpenRC being in @system. Personally I'm a fan of > getting rid of @system entirely except as something used to build > install CDs or having some sets for convenience in building systems. It > only exists for a few reasons that I can think of: > 1. Devs don't want to have ebuilds that capture dependencies on every > little thing. A few well-chosen virtuals like "shell utilities" or > whatever might help with this. > 2. Things like Prefix rely on the system not installing local copies of > libraries in the core system it needs to link to. Careful use of > package.provided in profiles might address this. > 3. We'd need many more virtuals to handle situations like FreeBSD where > people don't what GNU on their systems. Right now if they are system > packages they just define system appropriately and ebuilds don't > directly pull in the GNU stuff anyway. AFAIK, @system also helps resolve a few nasty circular dependencies. In fact, I believe that's it's primary purpose. As such I'm not sure it's practical (as opposed to possible, cost/benefit simply makes it impractical) to entirely get rid of, but it does occur to me that sets would be an interesting way to go. Define a few sets that together compose @system as we have it today, and basically package.provide them during the bootstrap phase. AFAIK the original stage tarball also contains a minimal installed tree, for similar reasons. I'm not actually sure how they interact. That'd be releng/arch/catalyst territory. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman