From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev-return-17343-arch-gentoo-dev=gentoo.org@lists.gentoo.org> Received: (qmail 20104 invoked from network); 12 Nov 2004 13:18:47 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 12 Nov 2004 13:18:47 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CSbKA-0003iO-Tg for arch-gentoo-dev@lists.gentoo.org; Fri, 12 Nov 2004 13:18:46 +0000 Received: (qmail 15015 invoked by uid 89); 12 Nov 2004 13:18:46 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: <mailto:gentoo-dev@gentoo.org> List-Help: <mailto:gentoo-dev-help@gentoo.org> List-Unsubscribe: <mailto:gentoo-dev-unsubscribe@gentoo.org> List-Subscribe: <mailto:gentoo-dev-subscribe@gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 26238 invoked from network); 12 Nov 2004 13:18:46 +0000 From: Jason Stubbs <jstubbs@gentoo.org> To: gentoo-dev@lists.gentoo.org Date: Fri, 12 Nov 2004 22:20:29 +0900 User-Agent: KMail/1.7.1 References: <1100130866.1286.34.camel@sirius.syd.operationaldynamics.com> <200411112157.41821.jstubbs@gentoo.org> <20041111170424.4b4c4bff.degrenier@easyconnect.fr> In-Reply-To: <20041111170424.4b4c4bff.degrenier@easyconnect.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411122220.29421.jstubbs@gentoo.org> Subject: Re: [gentoo-dev] Detecting gcj in ebuilds X-Archives-Salt: 4a105a6c-4593-48da-89f2-00698abac517 X-Archives-Hash: a63faccefcfbe1eec1330f0b00701113 On Friday 12 November 2004 01:04, Thomas de Grenier de Latour wrote: > On Thu, 11 Nov 2004 21:57:41 +0900 > > Jason Stubbs <jstubbs@gentoo.org> wrote: > > 1) Something Mr_Bones_ said - "Emerge should do the least amount > > of work necessary to fulfill a user's request". That seems like > > a logical statement to me. I also interpret that portage should > > do it if it can as well. > > That seems logical, but sometimes warning the user that his > request is stupid may be better for him. I mean, if emerging a > fortran program implies two gcc merges, and then emerging another > fortran program implies again two more gcc merges, etc., i think > the user will not be that happy of having been blindly obeyed. emerge --pretend will always show what emerge is going to do. > > Example time. :) > > I think it may help to also look at real world examples. As a > beginning, a quick grep on "re-emerge" in current tree gives me: <SNIP> > that in most cases, this deps are at least RDEPEND deps. That means that if > we want emerge to preserve system consistency (installed packages respect > make.conf+package.use flags), there is nothing clever to do for emerge, but > to fail at depend time and ask the user to change his flags and re-emerge > some packages (that is Olivier's example #7). > > So my opinion is that, _so far_, there seems to be no real need > for the clever solution you've proposed, and that the simpler > check and failure approach would be enough. But sure, that may not > be true anymore in the future (or with some packages that i've > missed). unixODBC-2.2.8.ebuild:DEPEND="qt? ( >=x11-libs/qt-3.0* )" qt-3.3.3-r1.ebuild:DEPEND="odbc? ( dev-db/unixODBC )" Don't let that '*' in unixODBC's DEPEND confuse you - that's somebody's misunderstanding and should be written as >=x11-libs/qt-3. This is one case that already exists in the tree and I'm certain that there are others. Even if there were no existing cases at present, not implementing it from the start is just a guaranteed bug. If the dep resolver has to be rewritten anyway, why not bring it up to scratch? Regards, Jason Stubbs -- gentoo-dev@gentoo.org mailing list