Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Jason Stubbs <jstubbs@g.o>
Subject: Re: Detecting gcj in ebuilds
Date: Fri, 12 Nov 2004 22:20:29 +0900
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@g.o> 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@g.o mailing list

Replies:
Re: Detecting gcj in ebuilds
-- Thomas de Grenier de Latour
Re: Detecting gcj in ebuilds
-- Dan Armak
References:
Detecting gcj in ebuilds
-- Andrew Cowie
Re: Detecting gcj in ebuilds
-- Jason Stubbs
Re: Detecting gcj in ebuilds
-- Thomas de Grenier de Latour
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Detecting gcj in ebuilds
Next by thread:
Re: Detecting gcj in ebuilds
Previous by date:
Re: Re: Policy for bugs because of CFLAGS (was: use flags)
Next by date:
Re: Detecting gcj in ebuilds


Updated Jun 17, 2009

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.