From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29423 invoked by uid 1002); 8 Sep 2003 00:03:21 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 31428 invoked from network); 8 Sep 2003 00:03:21 -0000 From: Jan Krueger Organization: microgalaxy.net To: Jon Portnoy Date: Mon, 8 Sep 2003 02:08:51 +0000 User-Agent: KMail/1.5.2 Cc: Gentoo-Dev References: <200309080132.45709.jk@microgalaxy.net> <20030907234111.GA9582@cerberus.oppresses.us> In-Reply-To: <20030907234111.GA9582@cerberus.oppresses.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309080208.51371.jk@microgalaxy.net> Subject: Re: [gentoo-dev] suggestion portage ebuild system file modification rights and protection X-Archives-Salt: 3c30a12a-c861-4325-a7bf-9f7fea25ad5a X-Archives-Hash: c959fdba7cd1e6b7bd8f2d70aa612384 On Sunday 07 September 2003 23:41, Jon Portnoy wrote: > You haven't explained why it's not sufficient. Read again. > > Again examples from the actual tree, so you can try yourself: > > 1. emerge ezmlm and emerge ezmlm-idx > > providing slightly different funtionality they will overwrite each other > > (instead of blocking each other) > > Bug. Is it filed? Bug in portage! portage is the one that allows such integrity mess. > So we don't have enough manpower. Thats true for many open-source project. Some of them just try to get organized more efficiently and succeed in doing so. So, maybe there is a more appropriate organization model for gentoo? > > And to me its clear why it is like that (at least on reason): i meant to say: (at least one reason) sorry. > So basically you're saying portage shouldn't install software. I say: portage must respect my system inegrity! > So we should never be able to tweak config files et al in an ebuild? an ebuild may freely modify its own config files. modification of config files not belonging to the ebuild should be done via an already suggested, secure abstraction, lets say a function like: changeconf phph.ini "line to add to phpini" portage could then intercept, respecting the suggested CONFIG_EXCLUDE or other user settings, or, if no user setting is the way, go to apply the change. This way it would be impossible for the ebuild to wipe php.ini. Also the user, via CONFIG_EXCLUDE, may completely switch of editing of php.ini by ebuilds. On the other hand, if the user doesnt care, the ebuild is free to add this line to php.ini. Jan -- gentoo-dev@gentoo.org mailing list