Re: [gentoo-dev] Detecting gcj in ebuilds

[Thomas de Grenier de Latour]

On Fri, 12 Nov 2004 22:20:29 +0900
Jason Stubbs <jstubbs@g.o> wrote:

> emerge --pretend will always show what emerge is going to do.

Sure, but you know how users are. Until .51, many users complained
about emerge that was marking "N" for slotted packages, that was
upgrading some injected packages, that was insisting to install
things because they were referenced in edb/virtuals, etc.
Everytime emerge's behavior goes a bit counter-intuitive, many
users are lost. And i think that seeing gcc re-emerged several
times on a world update will be counter-intuitive for many of
them. I agree that your approach is the right thing to do from a
reasonable semantics point of view, but from a user point of view
it will probably look different. 
  That said, this problem can also be solved by some cosmetic
means, like adding a big warning of that kind:
 * gcc will have to be emerged twice because you lack the fortran
 * USE flag, so if that is a problem for you, then add this flag
 * and you'll be fine. 10 9 8 7 6 5 4 3 2 1

> 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?

I completly agree on that, if things are rewrote from scratch,
there is no reason to re-introduce some known limitations that can
be avoided. 

My point was more that the "check and failure" approach is also
an acceptable short term solution, considering that it does not
need a complete rewrite of the deps solver, and will give similar
results (conflict/failure at depend time) on most existing cases.
Does it worth being implemented? I don't know, it depends what are
the plans for (or what is the status of) the deps solver
rewriting. If it is supposed to come in the next few months, then
i guess that this issue can just wait a bit more.

-- 
TGL.

--
gentoo-dev@g.o mailing list