1 |
On Sat, 2005-05-11 at 01:55 +0900, Jason Stubbs wrote: |
2 |
> On Friday 04 November 2005 22:33, Marius Mauch wrote: |
3 |
> > Ciaran McCreesh wrote: |
4 |
> > > On Thu, 03 Nov 2005 23:14:20 -0800 Brian <dol-sen@×××××.net> wrote: |
5 |
> > > | emerge -pv <package> |
6 |
> > > | |
7 |
> > > | would actually continue listing (modified normal)after finding a |
8 |
> > > | dependency is masked rather than stop on, and report only, the first |
9 |
> > > | one. The masked packages would need to be marked as such [hard |
10 |
> > > | masked, keyword masked], possibly shown grouped in blocks [KEYWORD, |
11 |
> > > | HARD MASKED, STABLE]. |
12 |
> > > |
13 |
> > > Problem is, once you hit one bad dependency, you can't carry on and |
14 |
> > > guarantee what the rest of the dep tree is going to be. Example: |
15 |
> > > |
16 |
> > > emerge -pv foo |
17 |
> > > |
18 |
> > > foo DEPENDs upon bar and baz |
19 |
> > > bar DEPENDS upon fnord, and is MASKED |
20 |
> > > baz DEPENDs upon || ( gerbil fnord ) |
21 |
> > |
22 |
> > Well, that and other semantic issues (what to do with multiple |
23 |
> > candidates for example?). |
24 |
> |
25 |
> Multiple candidates is the most worrying for me as well. a-1.1 is masked and |
26 |
> requires >=b-1.0. b has 1.0 and 1.1 both of which are masked. b-1.0 requires |
27 |
> c-1.0 while b-1.1 requires c-1.1. c-1.1 masked but c-1.0 isn't. Should the |
28 |
> above "keep going" just grab the highest *masked* version at each stage? |
29 |
> |
30 |
|
31 |
Isn't that what users end up with after adding each package to |
32 |
package.keywords then emerge-pv <package> again, and again... |
33 |
unless they do detailed research for each failed dep. I know I never |
34 |
looked that close at the packages each time it happened as long as it |
35 |
wasn't hard masked. |
36 |
|
37 |
> Either way, while there are bugs such as error messages being truncated, |
38 |
> requests such as "allow me to break my system easier" are truly far from my |
39 |
> mind. Of course, supplied patches will always be reviewed. |
40 |
> |
41 |
> -- |
42 |
> Jason Stubbs |
43 |
|
44 |
Well, I don't know that I could supply patches to portage. I have enough |
45 |
to keep track of in porthole let alone learn the intricacies of package |
46 |
management. It sounds like this is something easier done in porthole |
47 |
where we can display all relevant packages in a dialog with checkboxes |
48 |
for package selection and possibly an adjustable search depth. That way |
49 |
package research could be done in porthole's main window to help decide |
50 |
whether they wish to proceed and or which version to select. |
51 |
|
52 |
A real world example is gnome-base/gnome. The last couple updates have |
53 |
resulted in numerous masked packages needed to be added to |
54 |
package.keywords. |
55 |
|
56 |
|
57 |
Thanks for your time and input everyone. |
58 |
-- |
59 |
Brian <dol-sen@×××××.net> |
60 |
|
61 |
-- |
62 |
gentoo-portage-dev@g.o mailing list |