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