1 |
On Thu, 11 Nov 2004 21:57:41 +0900 |
2 |
Jason Stubbs <jstubbs@g.o> wrote: |
3 |
|
4 |
> 1) Something Mr_Bones_ said - "Emerge should do the least amount |
5 |
> of work necessary to fulfill a user's request". That seems like |
6 |
> a logical statement to me. I also interpret that portage should |
7 |
> do it if it can as well. |
8 |
|
9 |
That seems logical, but sometimes warning the user that his |
10 |
request is stupid may be better for him. I mean, if emerging a |
11 |
fortran program implies two gcc merges, and then emerging another |
12 |
fortran program implies again two more gcc merges, etc., i think |
13 |
the user will not be that happy of having been blindly obeyed. |
14 |
|
15 |
With the "failure at depend time" approach, what would happen is |
16 |
that the user would have to change is USE flags, re-emerge gcc |
17 |
once for all, and then he would be able to emerge as many fortran |
18 |
programs he wants. And his system would also stay consistent. That |
19 |
is, thanks to the human intervention it requires, a much smarter |
20 |
overall process imho. |
21 |
|
22 |
> Example time. :) |
23 |
|
24 |
I think it may help to also look at real world examples. As a |
25 |
beginning, a quick grep on "re-emerge" in current tree gives me: |
26 |
|
27 |
- sys-devel/gcc[gcj], sys-devel/gcc[java] |
28 |
Both DEPEND and RDEPEND (apps link to libgcj.so), despite it is |
29 |
implicit since it is a system package. |
30 |
Example: app-text/pdftk |
31 |
|
32 |
- sys-devel/gcc[fortran], sys-devel/gcc[f77], sys-devel/gcc[g77] |
33 |
(doh! Did the USE flag name really changed that often?) |
34 |
I think it is a DEPEND only, so this one fall into your #1 |
35 |
example. |
36 |
Example: app-sci/molden |
37 |
|
38 |
- sys-devel/gcc[multilib] |
39 |
Both DEPEND and RDEPEND. |
40 |
Example: games-emulation/zsnes |
41 |
|
42 |
- dev-python/gnome-python[gtkhtml] |
43 |
RDEPEND only. |
44 |
Example: media-sound/solfege |
45 |
|
46 |
- x11-libs/wxGTK[-unicode] |
47 |
Both DEPEND and RDEPEND. |
48 |
Example: media-sound/freqtweak |
49 |
|
50 |
- media-libs/gd[jpeg] |
51 |
Both DEPEND and RDEPEND. |
52 |
Example: app-admin/analog |
53 |
|
54 |
- x11-libs/qt[mysql] |
55 |
Both DEPEND and RDEPEND. |
56 |
Example: media-tv/mythfrontend |
57 |
|
58 |
- dev-dotnet/gtk-sharp[gnome] |
59 |
Both DEPEND and RDEPEND. |
60 |
Example: dev-dotnet/gtksourceview-sharp |
61 |
|
62 |
- dev-dotnet/gtk-sharp[gtkhtml] |
63 |
Both DEPEND and RDEPEND. |
64 |
Example: dev-util/monodoc |
65 |
|
66 |
- media-libs/imlib2[X] |
67 |
Both DEPEND and RDEPEND. |
68 |
Example: media-libs/giblib |
69 |
|
70 |
- dev-php/php[session], dev-php/mod_php[session] |
71 |
Both DEPEND and RDEPEND. |
72 |
Example: www-apps/mythweb |
73 |
|
74 |
This list is for sure not complete, but what we can see is that in |
75 |
most cases, this deps are at least RDEPEND deps. That means that |
76 |
if we want emerge to preserve system consistency (installed |
77 |
packages respect make.conf+package.use flags), there is nothing |
78 |
clever to do for emerge, but to fail at depend time and ask the |
79 |
user to change his flags and re-emerge some packages (that is |
80 |
Olivier's example #7). |
81 |
|
82 |
The only exception is g77, but i think "fortran" is a default USE |
83 |
flag in most profiles, no? So there should not be that many users |
84 |
missing that compiler, and if there are any, my opinion is that |
85 |
they will prefer to have a bit of manual work to do than to look |
86 |
emerge reinstalling gcc several times. |
87 |
|
88 |
So my opinion is that, _so far_, there seems to be no real need |
89 |
for the clever solution you've proposed, and that the simpler |
90 |
check and failure approach would be enough. But sure, that may not |
91 |
be true anymore in the future (or with some packages that i've |
92 |
missed). |
93 |
|
94 |
-- |
95 |
TGL. |
96 |
|
97 |
-- |
98 |
gentoo-dev@g.o mailing list |