Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/'

[Georgi Georgiev <chutz@gg3.net>]

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

Well, I never intended to rush things... bug #52415 has been open for
almost an year after all, and at least the config protection seems to be
more of a bug than a problem with the implementation (as I had posted in
a comment on the bug, $ROOT/etc/somefile is being checked against a list
that is not prefixed with a $ROOT).

The issue with the alternate configuration location is only a matter of
convenience, since it can be worked around with a couple of symlinks.
As your hands are full with other stuff, I'd only hope you keep the
request in mind. Maybe even post a note when you guys unknot the
spaghetti?

-- 
(    Georgi Georgiev   (  I went to a Grateful Dead Concert and they   (
 )    chutz@gg3.net     ) played for SEVEN hours. Great song. -- Fred   )
(   +81(90)6266-1163   (  Reuss                                        (
--
gentoo-dev@gentoo.org mailing list