1 |
On Wed, Mar 16, 2005 at 08:05:43AM +0900, Georgi Georgiev wrote: |
2 |
> maillog: 15/03/2005-12:01:47(-0600): Brian Jackson types |
3 |
> > On 10:14:14 am 2005-03-15 Georgi Georgiev <chutz@×××.net> wrote: |
4 |
> > > maillog: 15/03/2005-08:26:49(-0600): Brian Jackson types |
5 |
> > > > I have a bug filed for that too, but it's probably going to be a |
6 |
> > > > while before it's fixed. From what I've been told, it's not |
7 |
> > > > trivial to fix it because some of the config stuff isn't very |
8 |
> > > > well abstracted. |
9 |
> > > |
10 |
> > > It isn't? Are we talking about the same thing? After all, the |
11 |
> > > locations are just variables, that only need to be prefixed with |
12 |
> > > something. Could we get some input from whoever told you this? |
13 |
> > |
14 |
> > make.conf is easy. The profile isn't as easy. /etc/portage isn't easy |
15 |
> > at all. That's the basics. You'd have to ask the portage guys for more |
16 |
> > in depth info. |
17 |
> |
18 |
> I was hoping to get a response from them here. Portage guys, you there? |
19 |
http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/pym/config.py?root=gentoo-src |
20 |
^^^^ config class, cleaned up a bit from what stable has. |
21 |
|
22 |
At the moment, my focus on the bugger is the following- |
23 |
A) integration of env whitelist tracking, preferably in a an attached |
24 |
instance (the need for this is partially bound to covering |
25 |
filter-env's ass). |
26 |
B) either reorganize the beast so env stuff is accessible via an |
27 |
attribute, or create a container class that the config gets |
28 |
assigned into |
29 |
C) bind all tree instances to the config. Why? Kill off portage.db |
30 |
global usage entirely, and try and encapsulate data into one |
31 |
common, passable instance |
32 |
D) shift virtual loading, setcpv, setinst, load_infodir, etc, all out |
33 |
of config and to a proper class. |
34 |
|
35 |
So... why tack that stuff in now, when the class itself needs a major |
36 |
enema? :) |
37 |
|
38 |
Basically it comes down to a focus (at this point) in trying to |
39 |
improve the existing code/abstractions in use, rather then tacking |
40 |
more features/codepaths in. |
41 |
|
42 |
Anyone interested can take a crack at the request above, it's just not |
43 |
high on my peronsal (likely our) list of priorities, since the |
44 |
existing code is spaghetti like. |
45 |
|
46 |
Note that integration of env whitelisting *is* adding a new feature |
47 |
in. It's kind of required to keep things sane for the env handling |
48 |
though (mainly, a few very crazy var settings are *very* hard to |
49 |
properly filter). That and it can't be done without refactoring the |
50 |
config class anyways (which is intended)... |
51 |
~harring |
52 |
-- |
53 |
gentoo-dev@g.o mailing list |