-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Danny van Dyk wrote: > Am Montag, 11. September 2006 03:44 schrieb Zac Medico: >> Hi everyone, >> >> Portage currently has two hard-coded lists of variables that control >> the behavior of env-update. > The same applies to eselect env. > >> I'd like to make these variables >> configurable so that package maintainers have direct control over >> them. The variables break down into two basic types: colon >> separated and space separated. > Wrong, there is another type of var, namely those which are not > cummultative(sp?).
Okay, then how about if COLON_SEPARATED and SPACE_SEPARATED are represent cumulative variables, while all other variables are considered non-cumulative? >> What is the best way to propagate information about these two >> variable types? For example, we can have a list of variable names >> stored in a new variable called "COLON_SEPARATED" that will reside >> in either the profiles or /etc/env.d/ itself. Variable names not >> listed in COLON_SEPARATED can be assumed to be space separated. >> Does anyone have any ideas to share about how this information >> should be propagated? > a) You'd need two variables to store that info, as we have 3 classes > of envvars. > b) This is in no way related to the package tree. Those vars don't > magically change their class from colon separated to non > cummultative. I'd like to keep it hardcoded, as loading of such > variables can go wrong and you'd end up without a working env tool. We can store them in /etc/env.d/ itself. The env-update tool could be hare coded to consider COLON_SEPARATED and SPACE_SEPARATED as being implicitly within the SPACE_SEPARATED class. The tool would make one pass to accumulate those two variables, and then another pass to process the rest of the variables. Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFBYVD/ejvha5XGaMRAojeAKDxFNYaAk668XhmXVjELQVl5PppsACfX0/n Wmlxhwj+taaQ0H/aXoIswXI= =mLCw -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list
