From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RY3VM-0006pV-NW for garchives@archives.gentoo.org; Tue, 06 Dec 2011 22:28:53 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 31E0621C0DB; Tue, 6 Dec 2011 22:28:44 +0000 (UTC) Received: from mail-iy0-f181.google.com (mail-iy0-f181.google.com [209.85.210.181]) by pigeon.gentoo.org (Postfix) with ESMTP id E222A21C0D2 for ; Tue, 6 Dec 2011 22:27:53 +0000 (UTC) Received: by iaeo4 with SMTP id o4so2551751iae.40 for ; Tue, 06 Dec 2011 14:27:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=7D6VBa6F60zqdWsweWYJMnSK8HKdwtduuHSmY5Mx9bg=; b=Mck1JV0MkMTk/ns4NA+NJHl7QhC24mNpjGl8nYaZ+dIHTaLFvXxartEL4GXZhFbTVT lzfmYnm0hCKHYFmzlkpz4Jax2sn499fgCIG0zHdmovaOdiGp9Bk5ilV0phtbQ88xeTDZ H/pRJGCPulYRodGDPRLRTthgpkoZpzUWc5tqU= Received: by 10.42.135.69 with SMTP id o5mr17175070ict.34.1323210473391; Tue, 06 Dec 2011 14:27:53 -0800 (PST) Received: from smtp.gmail.com:587 ([2620:0:1000:fd10:224:d7ff:feae:c014]) by mx.google.com with ESMTPS id mb4sm52056260igc.1.2011.12.06.14.27.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Dec 2011 14:27:52 -0800 (PST) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Tue, 06 Dec 2011 14:27:48 -0800 Date: Tue, 6 Dec 2011 14:27:48 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles Message-ID: <20111206222748.GC18351@localhost.google.com> References: <201112061117.51390.vapier@gentoo.org> <201112061552.07652.vapier@gentoo.org> <20111206215255.GB18351@localhost.google.com> <201112061706.34344.vapier@gentoo.org> 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=us-ascii Content-Disposition: inline In-Reply-To: <201112061706.34344.vapier@gentoo.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: d790d010-de6d-4d80-82ae-7fa6d35450a9 X-Archives-Hash: 290a84d70dbcb1807ed464c2a2bfe8c6 On Tue, Dec 06, 2011 at 05:06:33PM -0500, Mike Frysinger wrote: > On Tuesday 06 December 2011 16:52:55 Brian Harring wrote: > > On Tue, Dec 06, 2011 at 03:52:07PM -0500, Mike Frysinger wrote: > > > On Tuesday 06 December 2011 14:28:02 Zac Medico wrote: > > > > On 12/06/2011 10:04 AM, Mike Frysinger wrote: > > > > > what might be interesting is if we had a "Gentoo default" set which > > > > > is what would come in a stage3 rather than the current "stage3 is > > > > > the system set". then we could move virtual/ssh out of the system > > > > > set and into the "Gentoo default" set so it'd be easier for people > > > > > to drop/etc... but i'm not familiar enough with the portage support > > > > > atm to say how feasible such an idea would be. > > > > > > > > Similar to how we use packages.build to define the stage1 set, we could > > > > add a packages.default to define the stage3 set. Alternatively, we > > > > could use a meta-package to pull in the defaults, and adjust the > > > > stage3 build to pull in that meta-package automatically. > > > > > > the packages.default sounds like a good idea as then we'd be able to > > > tweak/stack it on a per-profile basis like existing files. i'll file a > > > release bug on the topic, and then we can talk about moving virtual/ssh > > > out of system and into that. > > > > We really need something generic here rather than just introducing new > > files; this basically duplicates sets for example. > > sets isn't in stable portage yet, right ? and is it stackable in profiles ? Bluntly, portage set support from the tree isn't something I'm sure we really want to support /anyways/; it's fairly portage specific last I looked. Also, it isn't stackable from profiles. Simple example of why sets.conf cannot be relied on: # xorg sets [x11-module-rebuild] class = portage.sets.dbapi.VariableSet world-candidate = false variable = CATEGORY includes = x11-drivers Or using a literal overlay example: [jmbsvicetto sets] class = portage.sets.files.StaticFileSet multiset = true directory = ${repository:jmbsvicetto}/sets/ So for any non portage PM, we'd have to translate portage class name paths, know the actual signature of the target (VariableSet for example), and perfectly emulate that- also emualate the ${var:default} interpolation. So... there's no way in hell sets.conf can, nor should be, relied on if we're even pretending to try and support multiple managers. That's putting it nicely. :) package.[set-name] from profiles is a potential, although that doesn't work perfectly for overlays (which typically get their profile from the master, thus precluding the overlay from injecting a node into the set); could come up with something though. ~harring