1 |
On Tue, 6 Dec 2011 14:27:48 -0800 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
|
4 |
> On Tue, Dec 06, 2011 at 05:06:33PM -0500, Mike Frysinger wrote: |
5 |
> > On Tuesday 06 December 2011 16:52:55 Brian Harring wrote: |
6 |
> > > On Tue, Dec 06, 2011 at 03:52:07PM -0500, Mike Frysinger wrote: |
7 |
> > > > On Tuesday 06 December 2011 14:28:02 Zac Medico wrote: |
8 |
> > > > > On 12/06/2011 10:04 AM, Mike Frysinger wrote: |
9 |
> > > > > > what might be interesting is if we had a "Gentoo default" |
10 |
> > > > > > set which is what would come in a stage3 rather than the |
11 |
> > > > > > current "stage3 is the system set". then we could move |
12 |
> > > > > > virtual/ssh out of the system set and into the "Gentoo |
13 |
> > > > > > default" set so it'd be easier for people to drop/etc... |
14 |
> > > > > > but i'm not familiar enough with the portage support atm to |
15 |
> > > > > > say how feasible such an idea would be. |
16 |
> > > > > |
17 |
> > > > > Similar to how we use packages.build to define the stage1 |
18 |
> > > > > set, we could add a packages.default to define the stage3 |
19 |
> > > > > set. Alternatively, we could use a meta-package to pull in |
20 |
> > > > > the defaults, and adjust the stage3 build to pull in that |
21 |
> > > > > meta-package automatically. |
22 |
> > > > |
23 |
> > > > the packages.default sounds like a good idea as then we'd be |
24 |
> > > > able to tweak/stack it on a per-profile basis like existing |
25 |
> > > > files. i'll file a release bug on the topic, and then we can |
26 |
> > > > talk about moving virtual/ssh out of system and into that. |
27 |
> > > |
28 |
> > > We really need something generic here rather than just |
29 |
> > > introducing new files; this basically duplicates sets for example. |
30 |
> > |
31 |
> > sets isn't in stable portage yet, right ? and is it stackable in |
32 |
> > profiles ? |
33 |
> |
34 |
> Bluntly, portage set support from the tree isn't something I'm sure |
35 |
> we really want to support /anyways/; it's fairly portage specific |
36 |
> last I looked. Also, it isn't stackable from profiles. |
37 |
> |
38 |
> Simple example of why sets.conf cannot be relied on: |
39 |
> |
40 |
> # xorg sets |
41 |
> [x11-module-rebuild] |
42 |
> class = portage.sets.dbapi.VariableSet |
43 |
> world-candidate = false |
44 |
> variable = CATEGORY |
45 |
> includes = x11-drivers |
46 |
> |
47 |
> Or using a literal overlay example: |
48 |
> [jmbsvicetto sets] |
49 |
> class = portage.sets.files.StaticFileSet |
50 |
> multiset = true |
51 |
> directory = ${repository:jmbsvicetto}/sets/ |
52 |
> |
53 |
> So for any non portage PM, we'd have to translate portage class name |
54 |
> paths, know the actual signature of the target (VariableSet for |
55 |
> example), and perfectly emulate that- also emualate the |
56 |
> ${var:default} interpolation. |
57 |
|
58 |
We wanted to replace that class with some global/generic vars, noone |
59 |
was interested in cooperating. Especially the-one-whose-name-shall- |
60 |
-not-be-spoken-aloud-or-he-will-come-with-his-metaphores. |
61 |
|
62 |
-- |
63 |
Best regards, |
64 |
Michał Górny |