From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org)
	by nuthatch.gentoo.org with esmtp (Exim 4.43)
	id 1E7FJS-0000wj-LY
	for garchives@archives.gentoo.org; Mon, 22 Aug 2005 16:38:19 +0000
Received: from robin.gentoo.org (localhost [127.0.0.1])
	by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7MGabKm031681;
	Mon, 22 Aug 2005 16:36:37 GMT
Received: from www.opersys.com (opersys.com [64.40.108.71])
	by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j7MGaZp4004260
	for <gentoo-portage-dev@lists.gentoo.org>; Mon, 22 Aug 2005 16:36:36 GMT
Received: from [192.168.172.55] (modemcable172.15-70-69.static.videotron.ca [69.70.15.172])
	by www.opersys.com (8.9.3/8.9.3) with ESMTP id KAA14932
	for <gentoo-portage-dev@lists.gentoo.org>; Mon, 22 Aug 2005 10:12:05 -0700
Subject: Re: [gentoo-portage-dev] Re: Environment Whitelisting
From: Kristian Benoit <kbenoit@opersys.com>
To: gentoo-portage-dev@lists.gentoo.org
In-Reply-To: <43095761.3080609@gmail.com>
References: <4308E349.8010107@egr.msu.edu>
	 <20050822035207.GA26017@phaenix.haell.com>  <43095761.3080609@gmail.com>
Content-Type: text/plain
Date: Mon, 22 Aug 2005 12:29:59 -0400
Message-Id: <1124728200.6502.37.camel@localhost>
Precedence: bulk
List-Post: <mailto:gentoo-portage-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-portage-dev+help@gentoo.org>
List-Unsubscribe: <mailto:gentoo-portage-dev+unsubscribe@gentoo.org>
List-Subscribe: <mailto:gentoo-portage-dev+subscribe@gentoo.org>
List-Id: Gentoo Linux mail <gentoo-portage-dev.gentoo.org>
X-BeenThere: gentoo-portage-dev@gentoo.org
Reply-to: gentoo-portage-dev@lists.gentoo.org
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1.1 
Content-Transfer-Encoding: 7bit
X-Archives-Salt: 7ce3c989-7e3b-4405-95e1-bc093e78f7c5
X-Archives-Hash: 8a71bf1cde4a2024d5ddae2ff58110d8

On Sun, 2005-08-21 at 21:41 -0700, Zac Medico wrote:
> Yeah, I agree that a build that is fragile with regard to environment
> variables could be an upstream issue.  The advantage of
> white/black/override list portage feature is that it would provide a
> way to work around these kinds of problems (until they are fixed
> upstream).

Another point of view could be that leaving the environment as is would
help providing bugs to the upstream. But I must agree with you that
having it optional would probably be the best thing.

I think the fourth solution would be nice if we have
a /etc/portage/package.env so that if one need to specify an non portage
environment variable, it could be specified on a per packge basis. It
could also be a /etc/portage/package.env.d that contain a per-package
script that set-up the environment for that package.

The script coud be called with the calling environment set a variable
name "keep_variables" to a list of the variables that should be kept for
that particuliar package.

The calling environment could also specify a keep_variables varible so
that we keep those variable in build environment.

Kristian

-- 
gentoo-portage-dev@gentoo.org mailing list