1 |
On Saturday 05 November 2005 03:03, felix@×××××××.com wrote: |
2 |
> On Sat, Nov 05, 2005 at 01:55:35AM +0900, Jason Stubbs wrote: |
3 |
> > On Friday 04 November 2005 22:33, Marius Mauch wrote: |
4 |
> > > Ciaran McCreesh wrote: |
5 |
> > > > On Thu, 03 Nov 2005 23:14:20 -0800 Brian <dol-sen@×××××.net> wrote: |
6 |
> > > > | emerge -pv <package> |
7 |
> > > > | |
8 |
> > > > | would actually continue listing (modified normal)after finding a |
9 |
> > > > | dependency is masked rather than stop on, and report only, the |
10 |
> > > > | first one. The masked packages would need to be marked as such |
11 |
> > > > | [hard masked, keyword masked], possibly shown grouped in blocks |
12 |
> > > > | [KEYWORD, HARD MASKED, STABLE]. |
13 |
> > > > |
14 |
> > > > Problem is, once you hit one bad dependency, you can't carry on and |
15 |
> > > > guarantee what the rest of the dep tree is going to be. Example: |
16 |
> > > > |
17 |
> > > > emerge -pv foo |
18 |
> > > > |
19 |
> > > > foo DEPENDs upon bar and baz |
20 |
> > > > bar DEPENDS upon fnord, and is MASKED |
21 |
> > > > baz DEPENDs upon || ( gerbil fnord ) |
22 |
> > > |
23 |
> > > Well, that and other semantic issues (what to do with multiple |
24 |
> > > candidates for example?). |
25 |
> > |
26 |
> > Multiple candidates is the most worrying for me as well. a-1.1 is masked |
27 |
> > and requires >=b-1.0. b has 1.0 and 1.1 both of which are masked. b-1.0 |
28 |
> > requires c-1.0 while b-1.1 requires c-1.1. c-1.1 masked but c-1.0 isn't. |
29 |
> > Should the above "keep going" just grab the highest *masked* version at |
30 |
> > each stage? |
31 |
> > |
32 |
> > Either way, while there are bugs such as error messages being truncated, |
33 |
> > requests such as "allow me to break my system easier" are truly far from |
34 |
> > my mind. Of course, supplied patches will always be reviewed. |
35 |
> |
36 |
> Wait a sec -- |
37 |
> |
38 |
> emerge -pv means pretend, so it can't break anything. Furthermore, |
39 |
> even without the -p, no one is asking it to keep on going, only asking |
40 |
> that it show all errors it can find before bailing. Its current |
41 |
> behavior is like a compiler that aborts on the first error. I would |
42 |
> rather it go on, show me all errors, until it either gets too many, or |
43 |
> runs out of them, rather than bailing on the first one. |
44 |
|
45 |
So what exactly should it do? Let's take the above example a bit further? |
46 |
|
47 |
a-1.1 masked reqs >=b-1.0 |
48 |
b-1.0 masked reqs nothing, b-1.1 masked reqs >=c-1.0 |
49 |
c-1.0 not masked, c-1.1 masked reqs >=d-1.0, c-1.2 masked reqs >=d-1.1 |
50 |
d-1.0 masked, d-1.1 masked, d-1.2 masked. |
51 |
|
52 |
Should emerge tell the user that unmasking b-1.0 is the "best" action. Should |
53 |
it suggest that b-1.1, c-1.2 and d-1.2 should all be unmasked? Should it |
54 |
output all of the above masking information? What is the benefit of |
55 |
continuing in the face of so much missing information when the user will have |
56 |
to make a choice (that portage alerts the user to already) at each package |
57 |
level anyway? |
58 |
|
59 |
> Further, it would be nice if emerge behaved more like make -k, or had |
60 |
> an equivalent option. It wouldn't hurt anything if it were to give up |
61 |
> on one package and continue to the next if possible. If foo depends |
62 |
> on bar, and bar fails, sure bail on foo, but why not continue with the |
63 |
> next candidate if it doesn't depend on either? |
64 |
|
65 |
This is bug #12768. This is possible. |
66 |
http://bugs.gentoo.org/show_bug.cgi?id=12768 |
67 |
|
68 |
-- |
69 |
Jason Stubbs |
70 |
-- |
71 |
gentoo-portage-dev@g.o mailing list |