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 1RY4BD-0003km-S4 for garchives@archives.gentoo.org; Tue, 06 Dec 2011 23:12:08 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 85E2B21C295; Tue, 6 Dec 2011 23:11:58 +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 F14BE21C0FE for ; Tue, 6 Dec 2011 23:10:55 +0000 (UTC) Received: by iaeo4 with SMTP id o4so2605362iae.40 for ; Tue, 06 Dec 2011 15:10:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=kISuKoIhW/MMAIzJYQKNk5pL+SZTz84pd0N4mQito3k=; b=dea0MVnm+rlJDmKZSDGaUs/XCqe9wofRfFpY5xVTmZST/odjd1yVM2YT4FU+QD2/lD I4XXwk8co7/NZUye9/im+k6PXPOp9675XGrd2frZSs90LiLV8lsjtzPovAe+zNbOU8Q/ OCzU9xkRvalbcysqETBy/IemnZ9l53pVMpUQE= Received: by 10.42.137.69 with SMTP id x5mr16360329ict.19.1323213055503; Tue, 06 Dec 2011 15:10:55 -0800 (PST) Received: from smtp.gmail.com:587 ([2620:0:1000:fd10:224:d7ff:feae:c014]) by mx.google.com with ESMTPS id zs7sm11461768igb.0.2011.12.06.15.10.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Dec 2011 15:10:54 -0800 (PST) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Tue, 06 Dec 2011 15:10:50 -0800 Date: Tue, 6 Dec 2011 15:10:50 -0800 From: Brian Harring To: Micha?? G??rny Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles Message-ID: <20111206231050.GD18351@localhost.google.com> References: <201112061117.51390.vapier@gentoo.org> <201112061552.07652.vapier@gentoo.org> <20111206215255.GB18351@localhost.google.com> <201112061706.34344.vapier@gentoo.org> <20111206222748.GC18351@localhost.google.com> <20111206233428.00f95b42@pomiocik.lan> 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: <20111206233428.00f95b42@pomiocik.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 02564271-1442-4e78-9d42-0f6669340215 X-Archives-Hash: 66d31dddff71ac7ac1862e1079572096 On Tue, Dec 06, 2011 at 11:34:28PM +0100, Micha?? G??rny wrote: > On Tue, 6 Dec 2011 14:27:48 -0800 > Brian Harring wrote: > > 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. > > We wanted to replace that class with some global/generic vars, noone > was interested in cooperating. Especially the-one-whose-name-shall- > -not-be-spoken-aloud-or-he-will-come-with-his-metaphores. It's not that people aren't interested in sets, it's that the proposal of trying to mutate sets.conf into something people would be happy with is fucked from the get go. Keep in mind pkgcore actually already supports the basic format (minus a few tweaks, this is pkgcore's raw ini format for when people need to screw w/ the absolute guts of it). It is *not* a good format for compatibility; adding a couple global/generic class names (basic schemas) still leaves open the ability for people to force PM specific class settings, getting us right back into the original criticism I leveled- specifically leaving PM's having to continually play "emulate the portage api". It's a shitty situation to be in, and not one alternative PM authors are going to willingly walk into. sets.conf isn't viable; this was known when it was originally forced in. package.[setname] for a static list of atoms is a fairly good start; profiles could stack it (reusing existing stack logic), and repositories could grow metadata/sets/[name] as a base to use for example. One thing people need to agree on /prior to implementing this/, is how overlays will interact here. Can they mutate an existing set? etc. Other thing to note, we should probably use a different name than package.*; set.* is saner. If we use package.*, a naive implementation could interpret package.use* as a set. ~harring