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 45FAA1381F4 for ; Wed, 15 Aug 2012 19:19:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1A47F21C01D; Wed, 15 Aug 2012 19:19:28 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 92BEBE09A2 for ; Wed, 15 Aug 2012 19:18:25 +0000 (UTC) Received: by bkwj4 with SMTP id j4so846489bkw.40 for ; Wed, 15 Aug 2012 12:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=iwzrszm33p0xVcKMz2QwT6Xl8TmLhGKvsEPnF3rPzRQ=; b=HFrUx0oRtpFyamF9kaNnN+zHfUSK+MrhFXJ8k4b/LOYlNujSRsj0SnApzleC9Ke35g gHj+ACZCCFLNDNqw0zUUYbjWdHrYESdtkHyqh0voFfj3OQhfHQm2lyQGJJTvorjai439 RpTWou/V0Dh4FJckLM3Mczl21Sz2trKRp2ARpZn6aeACEEqvhweLZDSVKRRE6khwLnfU n0kPdX7j1MkSfEDPfUQl0ukeap/mzmYEkK2ROG+rJBIJVFhEchJBzt9w3n4E82qRE5Ho XXc5mo7x4FROMokBSsrScc76Ufwp8Ha/b+ixYkhIq77Ufg8qGf0EOinqRcDo5MhhCs4o FdDQ== 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 Received: by 10.204.5.144 with SMTP id 16mr8050813bkv.128.1345058304409; Wed, 15 Aug 2012 12:18:24 -0700 (PDT) Received: by 10.205.25.8 with HTTP; Wed, 15 Aug 2012 12:18:24 -0700 (PDT) In-Reply-To: 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> Date: Wed, 15 Aug 2012 15:18:24 -0400 Message-ID: Subject: Re: [gentoo-dev] Re: Questions about SystemD and OpenRC From: Michael Mol To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: da4f070c-dfbf-47d3-b404-92e56f0b5e95 X-Archives-Hash: e375103dd9cd60f3335ba6137dcc916e On Wed, Aug 15, 2012 at 2:21 PM, Duncan <1i5t5.duncan@cox.net> wrote: > > 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. Just piping up here, as this relates to an idea that's been percolating through my mind for a couple weeks. I've occasionally noticed portage tell me about circular dependencies, where the most straight forward resolution is to emerge some package in the loop twice. The first time, with a USE flag disabled (avahi and gtk are the usual suspects), and the second time with the USE flag enabled. In circumstances where it's necessary to do something like that to reach a final desired system state, I'm not sure I see any problem with portage automatically doing the two-stage emerge. It also sounds like something like that could be a benefit to shrinking @system. As far as things such as libc, where many, many packages require their use, I don't personally see a problem with recommending that ebuilds depend on them. My only other notable experience for Linux distributions is Debian/Ubuntu, and a quick glance shows 16,389 packages expressing explicit dependencies on libc6 in Ubuntu 12.04. -- :wq