On Tue, 6 Dec 2011 14:27:48 -0800 Brian Harring <ferri...@gmail.com> wrote:
> 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.
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.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
