1 |
On Friday 12 November 2004 01:04, Thomas de Grenier de Latour wrote: |
2 |
> On Thu, 11 Nov 2004 21:57:41 +0900 |
3 |
> |
4 |
> Jason Stubbs <jstubbs@g.o> wrote: |
5 |
> > 1) Something Mr_Bones_ said - "Emerge should do the least amount |
6 |
> > of work necessary to fulfill a user's request". That seems like |
7 |
> > a logical statement to me. I also interpret that portage should |
8 |
> > do it if it can as well. |
9 |
> |
10 |
> That seems logical, but sometimes warning the user that his |
11 |
> request is stupid may be better for him. I mean, if emerging a |
12 |
> fortran program implies two gcc merges, and then emerging another |
13 |
> fortran program implies again two more gcc merges, etc., i think |
14 |
> the user will not be that happy of having been blindly obeyed. |
15 |
|
16 |
emerge --pretend will always show what emerge is going to do. |
17 |
|
18 |
> > Example time. :) |
19 |
> |
20 |
> I think it may help to also look at real world examples. As a |
21 |
> beginning, a quick grep on "re-emerge" in current tree gives me: |
22 |
<SNIP> |
23 |
> that in most cases, this deps are at least RDEPEND deps. That means that if |
24 |
> we want emerge to preserve system consistency (installed packages respect |
25 |
> make.conf+package.use flags), there is nothing clever to do for emerge, but |
26 |
> to fail at depend time and ask the user to change his flags and re-emerge |
27 |
> some packages (that is Olivier's example #7). |
28 |
> |
29 |
> So my opinion is that, _so far_, there seems to be no real need |
30 |
> for the clever solution you've proposed, and that the simpler |
31 |
> check and failure approach would be enough. But sure, that may not |
32 |
> be true anymore in the future (or with some packages that i've |
33 |
> missed). |
34 |
|
35 |
unixODBC-2.2.8.ebuild:DEPEND="qt? ( >=x11-libs/qt-3.0* )" |
36 |
qt-3.3.3-r1.ebuild:DEPEND="odbc? ( dev-db/unixODBC )" |
37 |
|
38 |
Don't let that '*' in unixODBC's DEPEND confuse you - that's somebody's |
39 |
misunderstanding and should be written as >=x11-libs/qt-3. This is one case |
40 |
that already exists in the tree and I'm certain that there are others. Even |
41 |
if there were no existing cases at present, not implementing it from the |
42 |
start is just a guaranteed bug. If the dep resolver has to be rewritten |
43 |
anyway, why not bring it up to scratch? |
44 |
|
45 |
Regards, |
46 |
Jason Stubbs |
47 |
|
48 |
-- |
49 |
gentoo-dev@g.o mailing list |