From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.3/8.13.3) with ESMTP id j2G3ZwTh002231 for ; Wed, 16 Mar 2005 03:35:58 GMT Received: from 142.13.111.219.st.bbexcite.jp ([219.111.13.142] helo=tiger.gg3.net) by smtp.gentoo.org with esmtp (Exim 4.43) id 1DBPK9-0005L5-Es for gentoo-dev@robin.gentoo.org; Wed, 16 Mar 2005 03:35:57 +0000 Received: (qmail 12653 invoked by uid 1000); 16 Mar 2005 12:35:55 +0900 Date: Wed, 16 Mar 2005 12:35:55 +0900 From: Georgi Georgiev To: gentoo-dev@robin.gentoo.org Subject: Re: [gentoo-dev] CONFIG_PROTECT and ROOT!='/' Message-ID: <20050316033555.GE10968@tiger.gg3.net> Mail-Followup-To: gentoo-dev@gentoo.org References: <4235BFB0.70907@rle.ru> <4236004E.1010007@gentoo.org> <1110860664.11759.3.camel@matrix.brianandsara.net> <20050315065600.GA5908@ols-dell.iic.hokudai.ac.jp> <20050315161413.GA17344@lion.gg3.net> <20050315230543.GB7990@lion.gg3.net> <20050316031726.GA23157@freedom.wit.com> Precedence: bulk List-Post: , , List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-To: gentoo-dev@gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050316031726.GA23157@freedom.wit.com> User-Agent: Mutt/1.5.6i X-Archives-Salt: 0ce97910-db4e-4559-b4de-f7aff90b0572 X-Archives-Hash: 9710c7adadf4f65dd4e7a5f60e9d44c8 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 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