On Friday 12 November 2004 01:04, Thomas de Grenier de Latour wrote:
> On Thu, 11 Nov 2004 21:57:41 +0900
> Jason Stubbs <email@example.com> 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:
> 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
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?
firstname.lastname@example.org mailing list