/[gentoo-src]/portage/rewrite-misc/conf_default_types
Gentoo

Contents of /portage/rewrite-misc/conf_default_types

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.6 - (show annotations) (download)
Tue Aug 9 08:41:58 2005 UTC (7 years, 9 months ago) by ferringb
Branch: MAIN
CVS Tags: HEAD
Changes since 1.5: +5 -4 lines
update for ACCEPT_LICENSE filtering

1 # so what the hell does this all mean? It's section type definitions.
2 # defaults specifies the name of default settings, which much exist in the section definition.
3 # required specifies what settings are required in any user config for that section.
4 # incrementals specifies what settings are stacked, orig_setting + new_setting. not limited to list types only, but probably should be
5 # list, str, bool are lists of settings, stating "this setting is of this type", so at runtime any config settings processed are
6 # automatically converted to that type.
7 # section_ref are a _special_ type of setting type. must reference another section, and can be multiple (specified via list).
8 # not possible to do incrementals on section types, so don't attempt it (it will not act as you expect).
9 # note defaults get passed through the setting type conversion mechanism also.
10 # instantiate is the python namespace addie of a callable that does instantiation of that section (rather then a generic handler).
11 # generic handler ignores any settings that don't fall aren't addressed/fscked with via default mangling mentioned above
12 # (change this later?)
13 #
14 # any defined section setting types that are in the config are verified to exist during config collapsing.
15 # if a custom instantiation func is defined for that section type, the instantiation func is required to instantiate the sections
16 # (config.instantiate_section(section) effectively). Otherwise, the generic handler does the instantiation are substition for
17 # callable instantiation on it's own.
18 #
19 # positional specifies positional args (which all must be required), only actually used if generic instantiator is used.
20 # label is special setting name, akin to __name__ (literally, that's it value), *only* when stated as a default
21 #
22 # iow, if you have your own instantiation func for a section, you have to instantiate any section types you define. it's verified
23 # to exist, but type is not verified (class type verification within specified callable should suffice however).
24 #
25 # custom instantiation func prototype (the actual instantiation handler):
26 # def handler(config, callable, section_label, section_config)
27 #
28 # config == portage.config.central.config instance,
29 # callable == class definition for that section,
30 # section_label == section's label/name (hard one I know).
31 # section_config == collapsed section's config as a dict.
32 #
33 #
34 # potential extensions:
35 #
36 # types are limited to what the generic parser knows of. that should be extended.
37 #
38 # inter-section references should be handled (instantiation) via the generic parser also.
39 # ex: instantiation of domain should be given instantiated repos/profiles instead of section names.
40 #
41 # there is no way to have defaults represented at the config level for specialized callables.
42 # decide if this is good or bad. in effect, require's are generalized for a section type, which may not apply
43 #
44 # there isn't any mechanism for noting what supports interop (think sync + repo), aside from instantiating
45 # and having it complain. fluid design/intention of the final parsing of user config, but this is a drawback of
46 # said design.
47 # think about ways to curb that, lest users get too annoying with tracebacks ;)
48 #
49 # right now, there is now way to specify that a callable requires certain settings beyond section requirements.
50 # there _should_ be an automated way to get that info, so that the generic parser can carry that load.
51 #
52 # this file also will be 'fun' for doing per keyword defaults as per the portage norm.
53 # probably need to support exec within this file, with a default exec section pointing at
54 # a location on the fs that defines further defaults, although that makes parsing this file fun.
55 #
56 # short version, with the rules established, you would need to define a metasection, and apply the
57 # inherit/incrementals cruft to constructing at run time the section definitions.
58 # or you need a smarter parser/generator for this file.
59 # leave that to the schmuck who writes the autotools integration for this
60 # (why oh why do I suspect that's going to be my stupid ass? :)
61 # ~harring
62 #
63 # ps. a dpkg repo (fex) _should_ be a different section type imo, and whatever checks are done for
64 # assembling a domain should do isinstance checks on a repo base, rather then (potentially) enforcing
65 # type restriction in the config specification (repositories = section label, and verifying that label's type)
66 # or not. think about it...
67 #
68 # pps: any such isinstance check _must_ do the check after an instantiation attempt. remember that class is in reality
69 # a callable, which can include functions that are _not_ classes, but return objects via whatever screwed up logic internal
70 # to the func (think static factory func for accessing a singleton, although bad example since you can implement singleton
71 # within the class definition via __new__, but I digress)...
72 #
73 # ppps: if it's required, state it. don't assume just cause it is a default, that not listing a setting in required is valid
74 # it's anal, but it _will_ help to catch screwups in section definition changes.
75 #
76 # pppps: Fairly sure at some point the town folk will come around with the pitchforks, torches and that special glimmer in their eyes
77 # if positional args for initialization isn't supported in someway (regardless of the fun of implementing it), so think about
78 # possibilities for pulling it off (required ordering lifted from section def and/or callable?)
79
80
81 [profile]
82 list = %(default_incrementals)s package.keywords package.use package.unmask package.mask
83 defaults = class incrementals
84 incrementals = %(default_incrementals)s
85 class = portage.ebuild.profiles.OnDiskProfile
86 required = class incrementals base_repo profile
87 section_ref = base_repo
88 positional = base_repo profile incrementals
89
90 [domain]
91 #instantiate = portage.config.parser.domain
92 required = repositories profile root class incrementals ACCEPT_LICENSE
93 section_ref = repositories profile
94 list = %(default_incrementals)s %(package_filters)s package.unmask repositories
95 incrementals = %(default_incrementals)s
96 defaults = class root incrementals ACCEPT_LICENSE
97 class = portage.config.domain.domain
98 root = /
99 ACCEPT_LICENSE =
100 positional = incrementals root profile repositories
101
102 [repo]
103 required = class location
104 defaults = class
105 class = portage.ebuild.repository
106 section_ref = cache sync sync_cache
107
108 #package.keywords = portage.config.handler.keywords
109 #package.mask = portage.config.handler.mask
110 #package.unmask = portage.config.handler.unmask
111
112 [cache]
113 required = class location label auxdbkeys
114 defaults = class auxdbkeys location label readonly
115 class = portage.cache.flat_list.database
116 auxdbkeys = %(metadata_keys)s
117 location = %(cache_base_loc)s
118 readonly = false
119 list = auxdbkeys
120 positional = location label auxdbkeys
121 bool = readonly
122
123 [exec]
124 autoexec = true
125
126 [sync]
127 required = class url
128 defaults = class
129 class = portage.sync.rsync
130
131 [DEFAULT]
132 metadata_keys = DEPEND RDEPEND SLOT SRC_URI RESTRICT HOMEPAGE LICENSE DESCRIPTION KEYWORDS INHERITED IUSE CDEPEND
133 PDEPEND PROVIDE
134 cache_base_loc = /var/cache/edb/dep/
135 default_incrementals = USE FEATURES ACCEPT_KEYWORDS ACCEPT_LICENSE CONFIG_PROTECT_MASK CONFIG_PROTECT PRELINK_PATH PRELINK_PATH_MASK
136 package_filters = package.mask package.keywords package.license package.use

  ViewVC Help
Powered by ViewVC 1.1.13