On Saturday 05 November 2005 03:03, [EMAIL PROTECTED] wrote: > On Sat, Nov 05, 2005 at 01:55:35AM +0900, Jason Stubbs wrote: > > On Friday 04 November 2005 22:33, Marius Mauch wrote: > > > Ciaran McCreesh wrote: > > > > On Thu, 03 Nov 2005 23:14:20 -0800 Brian <[EMAIL PROTECTED]> wrote: > > > > | emerge -pv <package> > > > > | > > > > | would actually continue listing (modified normal)after finding a > > > > | dependency is masked rather than stop on, and report only, the > > > > | first one. The masked packages would need to be marked as such > > > > | [hard masked, keyword masked], possibly shown grouped in blocks > > > > | [KEYWORD, HARD MASKED, STABLE]. > > > > > > > > Problem is, once you hit one bad dependency, you can't carry on and > > > > guarantee what the rest of the dep tree is going to be. Example: > > > > > > > > emerge -pv foo > > > > > > > > foo DEPENDs upon bar and baz > > > > bar DEPENDS upon fnord, and is MASKED > > > > baz DEPENDs upon || ( gerbil fnord ) > > > > > > Well, that and other semantic issues (what to do with multiple > > > candidates for example?). > > > > Multiple candidates is the most worrying for me as well. a-1.1 is masked > > and requires >=b-1.0. b has 1.0 and 1.1 both of which are masked. b-1.0 > > requires c-1.0 while b-1.1 requires c-1.1. c-1.1 masked but c-1.0 isn't. > > Should the above "keep going" just grab the highest *masked* version at > > each stage? > > > > Either way, while there are bugs such as error messages being truncated, > > requests such as "allow me to break my system easier" are truly far from > > my mind. Of course, supplied patches will always be reviewed. > > Wait a sec -- > > emerge -pv means pretend, so it can't break anything. Furthermore, > even without the -p, no one is asking it to keep on going, only asking > that it show all errors it can find before bailing. Its current > behavior is like a compiler that aborts on the first error. I would > rather it go on, show me all errors, until it either gets too many, or > runs out of them, rather than bailing on the first one.
So what exactly should it do? Let's take the above example a bit further? a-1.1 masked reqs >=b-1.0 b-1.0 masked reqs nothing, b-1.1 masked reqs >=c-1.0 c-1.0 not masked, c-1.1 masked reqs >=d-1.0, c-1.2 masked reqs >=d-1.1 d-1.0 masked, d-1.1 masked, d-1.2 masked. Should emerge tell the user that unmasking b-1.0 is the "best" action. Should it suggest that b-1.1, c-1.2 and d-1.2 should all be unmasked? Should it output all of the above masking information? What is the benefit of continuing in the face of so much missing information when the user will have to make a choice (that portage alerts the user to already) at each package level anyway? > Further, it would be nice if emerge behaved more like make -k, or had > an equivalent option. It wouldn't hurt anything if it were to give up > on one package and continue to the next if possible. If foo depends > on bar, and bar fails, sure bail on foo, but why not continue with the > next candidate if it doesn't depend on either? This is bug #12768. This is possible. http://bugs.gentoo.org/show_bug.cgi?id=12768 -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
