Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: Micha?? G??rny <mgorny@g.o>
From: Brian Harring <ferringb@...>
Subject: Re: sys-libs/ncurses: punted from system in profiles
Date: Tue, 6 Dec 2011 15:10:50 -0800
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@...> 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


References:
sys-libs/ncurses: punted from system in profiles
-- Mike Frysinger
Re: sys-libs/ncurses: punted from system in profiles
-- Mike Frysinger
Re: sys-libs/ncurses: punted from system in profiles
-- Brian Harring
Re: sys-libs/ncurses: punted from system in profiles
-- Mike Frysinger
Re: sys-libs/ncurses: punted from system in profiles
-- Brian Harring
Re: sys-libs/ncurses: punted from system in profiles
-- Michał Górny
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: sys-libs/ncurses: punted from system in profiles
Next by thread:
Re: sys-libs/ncurses: punted from system in profiles
Previous by date:
Re: sys-libs/ncurses: punted from system in profiles
Next by date:
Re: sys-libs/ncurses: punted from system in profiles


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.