Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: Micha?? G??rny <mgorny@g.o>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles
Date: Tue, 06 Dec 2011 23:12:08
In Reply to: Re: [gentoo-dev] sys-libs/ncurses: punted from system in profiles by "Michał Górny"
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 <ferringb@×××××.com> 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